Hi Malek, Thanks for the suggestions. I actually did start down the atomic Ruby route, but there are other issues there (competing asserts: AtomicSimple requires MemoryMode Atomic and Ruby requires MemoryMode Timing; removing the offending ones just led to crashes, even after implementing recvAtomic on the RubyPort).
You're right that switching FROM ruby would be a huge pain, but that wasn't ever going to happen. All my checkpoints would be AtomicSimple+Classic (so no cache data anyway). When I resumed each one, in the first few cycles, I would switch in the O3 cpu, then switch the inst and data ports over to the RubyPorts. Looks like I'll need to hook up other ports as well (pio bus is different between classic and ruby), but that's the general idea. -Mark -Mark On Fri, Nov 30, 2012 at 3:42 PM, Malek Musleh <[email protected]>wrote: > 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 <[email protected]> > 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 > > [email protected] > > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users > _______________________________________________ > gem5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
