I think these + one FS regression test that uses Ruby need to be updated
as well.
*****
build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing-ruby
FAILED!
*****
build/ALPHA_MOESI_CMP_token/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_token
FAILED!
*****
build/ALPHA_MOESI_CMP_token/tests/opt/quick/se/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_token
FAILED!
*****
build/ALPHA_MOESI_CMP_token/tests/opt/quick/se/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_token
FAILED!
***** build/MIPS/tests/opt/quick/se/00.hello/mips/linux/simple-timing-ruby
FAILED!
*****
build/SPARC/tests/opt/quick/se/00.hello/sparc/linux/simple-timing-ruby
FAILED!
***** build/X86/tests/opt/quick/se/00.hello/x86/linux/simple-timing-ruby
FAILED!
*****
build/ALPHA_MOESI_CMP_token/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby-MOESI_CMP_token
FAILED!
On Sun, 9 Sep 2012, Joel Hestness wrote:
Hey Nilay,
The only regressions that changed were those that use the Ruby memory
controller, and the only real changes were in the stats and config files.
Was there supposed to be something else here?
Thanks,
Joel
On Sun, Sep 9, 2012 at 2:08 PM, Nilay Vaish <[email protected]> wrote:
Joel, you did not update all the regression tests.
--
Nilay
On Fri, 7 Sep 2012, Joel Hestness wrote:
Hey Andreas,
I verified all the changes when I pushed these. The messy thing about
the Ruby regressions is that they use a tick length of 1ns instead of the
1ps which is default in the rest of the mainline. Because of this, the
400MHz default for the memory controller is converted to a 3 tick clock
(2.5ns = 2.5 ticks, rounded up), so everything there looks correct.
Regarding the stats differences, they are only present in the memory
bandwidth and the simulated runtime. These regressions were previously
using a 10 tick memory controller cycle, which equated to 10ns = 100MHz
(and a "crazy" 100GHz by default in the mainline with tick = 1ps). By
fixing the way the memory controller clock works - specifying the
frequency
and deriving the clock/cycle time from that - it fixes the crazy default
cycle time in the mainline. I set the default memory frequency to 400MHz
both as a somewhat more reasonable frequency than the really old default
of
200MHz, and as a way to verify that the stats changed in a reasonable way.
The memory bandwidth roughly doubles from the old regressions, which
makes sense: Previously, the memory frequency was 100MHz in these
regressions, and with the rounding to 3 ticks per cycle now, the new
frequency for the Ruby regressions is 333MHz. These regressions hammer
the
memory system to test the coherence protocols, so double memory bandwidth
is reasonable (and I've very thoroughly tested changing the frequency in
my
sandbox repo and every thing checks out). The simulated runtime gets cut
by approximately half because all of these regressions are memory
bandwidth
limited.
A bigger issue to note from this whole memory controller clocking issue
is that using a tick length of 1ns for these regressions is probably a bad
idea. In the case of this memory controller bug, the tick length masked
the clocking issue by setting the memory controller frequency at
effectively 100MHz in the regressions, while, if you change the tick
length, the memory controller frequency would change inversely
proportionally. In the future, I'd advocate for all regressions to use
the
default 1ps tick just so these sorts of bugs manifest themselves more
clearly, especially as all of the clocking changes are getting pushed
currently.
Joel
On Fri, Sep 7, 2012 at 10:27 AM, Andreas Hansson <[email protected]
**wrote:
Hi everyone,
It seems I was too optimistic. There are also quite some substantial
stats
differences for the regressions in question.
Joel, could you perhaps give them another bump (and a manual inspection
to
ensure it all makes sense)?
Andreas
-- IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose the
contents to any other person, use it for any purpose, or store or copy
the
information in any medium. Thank you.
______________________________**_________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/**listinfo/gem5-dev<http://m5sim.org/mailman/listinfo/gem5-dev>
--
Joel Hestness
PhD Student, Computer Architecture
Dept. of Computer Science, University of Wisconsin - Madison
<http://m5sim.org/mailman/**listinfo/gem5-dev<http://m5sim.org/mailman/listinfo/gem5-dev>
http://www.cs.utexas.edu/~**hestness<http://www.cs.utexas.edu/~hestness>
______________________________**_________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/**listinfo/gem5-dev<http://m5sim.org/mailman/listinfo/gem5-dev>
--
Joel Hestness
PhD Student, Computer Architecture
Dept. of Computer Science, University of Wisconsin - Madison
http://www.cs.utexas.edu/~hestness
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
