Hi Mark, I don't think it would be any easier, in fact it's probably more difficult to switch out memory systems. To ensure program correctness, even if a set of Ruby Caches and Classic Mem Caches were instantiated, you would need to flush from one to the other, and back between every sampling interval. Because Classic Mem and Ruby simulate different topologies (Bus-based vs. Directory-based), there really isn't a one-to-one mapping between a Ruby Cache to a Classic Mem Cache. This is assuming that the functionality to flush caches exists (It only exists for the hammer protocol in Ruby -- I am working on Flushing support for MOESI).
That being said, the other option (as you said) would be to support atomic accesses in ruby, and I *think* because that Ruby has some support? for functional accesses, that doing so would be a little easier anyway. I also don't know if O3 works with Ruby in a stable fashion (I know it works for some particular changeset according to mailing list posts, but I have not tried it on the latest dev change). Anyways, those are my thoughts on the matter. Others may have their own suggestions. Malek On Fri, Nov 30, 2012 at 4:20 PM, Mark Browning <mabrownin...@gmail.com> wrote: > Howdy all, > > I'm working on a sampling framework for gem5 in the same philosophy as > Simflex (http://parsa.epfl.ch/simflex/). However, fast forwarding Ruby is > proving tricky. I'd like to be able to run the whole simulation with > AtomicSimple, taking checkpoints at the sampling interval, then resume at > each checkpoint and run for a short sample with with Detailed+Ruby. > > The obvious choice of taking AtomicSimple checkpoints and restoring with > Detailed+Ruby has a problem during the small 500 cycle window after > restoring from the checkpoint (when its running AtomicSimple) that makes > this choice seem like a non-starter (I'd have to implement atomic memory > access in ruby... oy). > > Conversely, switching to Detailed or Timing during the fast-forward for a > few cycles before the checkpoints (so that I can use > --restore-with-cpu=[timing|detailed]) puts me in the Classic+O3 region, > which on x86 has correctness issues. > > tl;dr: > > Therefore, it seems like I need to switch both CPU and Memory systems > "simultaneously", but there is only support for switching CPU (while gem5 is > running). Are there any obvious pitfalls to using this same methodology for > instantiating but not "hooking up" Ruby, then at a later time, switching it > in? I'd have cold caches, but that's ok (problem to be tackled later). > > Thanks for any feedback or insights, > > -Mark Browning > > _______________________________________________ > gem5-users mailing list > gem5-users@gem5.org > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users _______________________________________________ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
