> 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? > > Steve Reinhardt wrote: > 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.
Here is the link to the discussion that took in June this year. http://www.mail-archive.com/[email protected]/msg00024.html I will add some comments to the function in question. - Nilay ----------------------------------------------------------- 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
