> On 2011-12-05 02:15:49, Gabe Black wrote: > > src/sim/eventq.hh, line 411 > > <http://reviews.m5sim.org/r/927/diff/1/?file=15916#file15916line411> > > > > One place you're using this is to slip an event to the front of the > > list, run it, and then put the head event back. That seems like a really > > bad way to do things. You could just call the process function on the event > > directly and avoid hacks like this. > > Nilay Vaish wrote: > That can be done, but in this case we want to ensure that no event > currently > on the event queue is processed, before Ruby is done with warming up > caches. > The call to simulate() will invoke the process() function of the just > inserted > event, which in turn will possibly insert many more events in the main > event > queue. We want all those events to get processed before other events > already > on the event queue. This was one of the ways suggested by Steve in a > discussion > several months back. > > Gabe Black wrote: > I still don't think this is a good idea. You'll process the warm up > events, then go back in time, and then process the real events. It all seems > like a giant hack. Maybe Steve can talk about why he suggested this approach?
It is a giant hack. I recall having a discussion on this where we went over several ugly alternatives, and identified one as least ugly. To be honest, it was quite a while ago and I don't remember all the alternatives we came up with or why this one seemed best in the end (or even that this was specifically the one we decided on). IIRC, basically Ruby does cache warmup by replaying a synthetic trace that's saved with the checkpoint, and it needs curTick to move monotonically forward to process that trace, but at the end of replaying the trace you need to make sure that curTick is still what it was when you started. Again, IIRC, the original code had two different event queues, the normal one and one that was only used for warmup, and a flag in each Ruby object telling it which queue to use. This approach of temporarily hijacking the global queue seemed like an improvement over that, since you just have one somewhat localized hack instead of a big distributed hack. That said, it definitely needs some comments explaining what this is for. - Steve ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/927/#review1725 ----------------------------------------------------------- On 2011-12-05 08:09:50, Nilay Vaish wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.m5sim.org/r/927/ > ----------------------------------------------------------- > > (Updated 2011-12-05 08:09:50) > > > Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and > Nathan Binkert. > > > Summary > ------- > > Ruby: Resurrect Cache Warmup Capability > This patch resurrects ruby's cache warmup capability. > > > Diffs > ----- > > configs/ruby/MOESI_hammer.py c1ab57ea8805 > configs/ruby/Ruby.py c1ab57ea8805 > src/mem/SConscript c1ab57ea8805 > src/mem/protocol/MOESI_CMP_token-L1cache.sm c1ab57ea8805 > src/mem/protocol/MOESI_CMP_token-L2cache.sm c1ab57ea8805 > src/mem/protocol/MOESI_CMP_token-dir.sm c1ab57ea8805 > src/mem/protocol/MOESI_hammer-cache.sm c1ab57ea8805 > src/mem/protocol/MOESI_hammer-dir.sm c1ab57ea8805 > src/mem/ruby/buffers/MessageBuffer.cc c1ab57ea8805 > src/mem/ruby/common/Global.hh c1ab57ea8805 > src/mem/ruby/common/Global.cc c1ab57ea8805 > src/mem/ruby/eventqueue/RubyEventQueue.hh c1ab57ea8805 > src/mem/ruby/eventqueue/RubyEventQueue.cc c1ab57ea8805 > src/mem/ruby/network/Network.hh c1ab57ea8805 > src/mem/ruby/network/Network.cc c1ab57ea8805 > src/mem/ruby/network/Topology.cc c1ab57ea8805 > src/mem/ruby/network/garnet/fixed-pipeline/GarnetNetwork_d.cc c1ab57ea8805 > src/mem/ruby/network/garnet/fixed-pipeline/NetworkInterface_d.cc > c1ab57ea8805 > src/mem/ruby/network/garnet/fixed-pipeline/OutVcState_d.cc c1ab57ea8805 > src/mem/ruby/network/garnet/fixed-pipeline/RoutingUnit_d.cc c1ab57ea8805 > src/mem/ruby/network/garnet/flexible-pipeline/GarnetNetwork.cc c1ab57ea8805 > src/mem/ruby/network/garnet/flexible-pipeline/NetworkInterface.cc > c1ab57ea8805 > src/mem/ruby/network/garnet/flexible-pipeline/Router.cc c1ab57ea8805 > src/mem/ruby/network/simple/PerfectSwitch.cc c1ab57ea8805 > src/mem/ruby/network/simple/SimpleNetwork.cc c1ab57ea8805 > src/mem/ruby/network/simple/Switch.cc c1ab57ea8805 > src/mem/ruby/network/simple/Throttle.cc c1ab57ea8805 > src/mem/ruby/recorder/CacheRecorder.hh c1ab57ea8805 > src/mem/ruby/recorder/CacheRecorder.cc c1ab57ea8805 > src/mem/ruby/recorder/SConscript c1ab57ea8805 > src/mem/ruby/recorder/TraceRecord.hh c1ab57ea8805 > src/mem/ruby/recorder/TraceRecord.cc c1ab57ea8805 > src/mem/ruby/recorder/Tracer.hh c1ab57ea8805 > src/mem/ruby/recorder/Tracer.cc c1ab57ea8805 > src/mem/ruby/recorder/Tracer.py c1ab57ea8805 > src/mem/ruby/slicc_interface/AbstractController.hh c1ab57ea8805 > src/mem/ruby/slicc_interface/AbstractController.cc c1ab57ea8805 > src/mem/ruby/system/Cache.py c1ab57ea8805 > src/mem/ruby/system/CacheMemory.hh c1ab57ea8805 > src/mem/ruby/system/CacheMemory.cc c1ab57ea8805 > src/mem/ruby/system/DMASequencer.hh c1ab57ea8805 > src/mem/ruby/system/MemoryControl.hh c1ab57ea8805 > src/mem/ruby/system/MemoryControl.cc c1ab57ea8805 > src/mem/ruby/system/RubyPort.hh c1ab57ea8805 > src/mem/ruby/system/RubyPort.cc c1ab57ea8805 > src/mem/ruby/system/SConscript c1ab57ea8805 > src/mem/ruby/system/Sequencer.hh c1ab57ea8805 > src/mem/ruby/system/Sequencer.cc c1ab57ea8805 > src/mem/ruby/system/System.hh c1ab57ea8805 > src/mem/ruby/system/System.cc c1ab57ea8805 > src/mem/slicc/symbols/StateMachine.py c1ab57ea8805 > src/sim/eventq.hh c1ab57ea8805 > > Diff: http://reviews.m5sim.org/r/927/diff > > > Testing > ------- > > > Thanks, > > Nilay > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
