[gem5-dev] Cron m5test@zizzer /z/m5/regression/do-regression quick

2013-10-08 Thread Cron Daemon
scons: `build/ALPHA_MOESI_hammer/tests/opt/quick/fs' is up to date. scons: `build/ALPHA_MESI_CMP_directory/tests/opt/quick/fs' is up to date. scons: `build/ALPHA_MOESI_CMP_directory/tests/opt/quick/fs' is up to date. scons: `build/ALPHA_MOESI_CMP_token/tests/opt/quick/fs' is up to date. scons:

Re: [gem5-dev] Review Request 2000: mem: Extend prefetcher with options and to work on non-block aligned addresses (prefetcher patch #1)

2013-10-08 Thread Mitch Hayenga
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2000/ --- (Updated Oct. 8, 2013, 1:42 p.m.) Review request for Default. Changes ---

Re: [gem5-dev] Review Request: PacketQueue: Add maxQueueDepth parameter and setter

2013-10-08 Thread Andreas Hansson
Hi Brad, I am actually inclined to say that the packet queue should only be used in simple devices to model pipeline latency, and that the value 100 is already too large. The only times I've hit this limit is when something in the model is broken and not reacting properly. Recently, we switched

Re: [gem5-dev] Review Request 1667: sim: simulate with multiple event queues

2013-10-08 Thread Nilay Vaish
On Wed, 25 Sep 2013, Andreas Hansson wrote: Hi Nilay, I'm afraid I won't have time to do that until next week sometime. In the meanwhile I have re-verified that the regressions are indeed getting 19% slower (by disabling your patch again). ~13hr with and ~11hr without. Andreas, were you

Re: [gem5-dev] Review Request 1667: sim: simulate with multiple event queues

2013-10-08 Thread Andreas Hansson
Hi Nilay, Unfortunately I haven't found the time to dig into this yet. I only have the output from last nights regression, and thus not with and without your patch. I'll take a snapshot and compare, although I suspect the individual runs vary quite a bit. Have you attempted any further

Re: [gem5-dev] Review Request: PacketQueue: Add maxQueueDepth parameter and setter

2013-10-08 Thread Beckmann, Brad
Yes, Andreas the Ruby interface uses the PacketQueue for the response packets after your changesets 8742 and 8914 (note the modifications to RubyPort.hh). Before you checked in these changes, the RubyPort used a simple timing port for response packets. I believe you checked in these changes