>From my perspective, there is only the second issue you mentioned, advancing >the simulator event queue to execute the warmup trace. Ruby already uses the >main event queue, so I view the first issue as some solved, though there is >still room for improvement.
I didn't mean to imply that Ruby would need to explicitly reset the clock. As you suggested, if Ruby is the first thing unserialized, the curTick will be reset correctly when the root object is unserialized. Similarly when states are reset, all Ruby stats incremented during the warmup phase will be reset. Assuming we can get the unserialized order correct, everything should just work without any explicit resets. The idea of a second event queue is an interesting alternative. How easy is it to point certain SimObjects at one event queue during one period of execution and another event queue at a different period? Brad > -----Original Message----- > From: [email protected] [mailto:gem5-dev- > [email protected]] On Behalf Of nathan binkert > Sent: Monday, June 20, 2011 10:20 AM > To: gem5 Developer List > Subject: Re: [gem5-dev] [m5-dev] Ruby Cache Warmup > > > The solution that Somayeh is working on will allow us to remove the ruby > event queue API. Ruby already uses the main event queue underneath for > all operations except cache warmup. When executing a warmup trace, the > event queue must move forward. If Ruby is the first SimObject unserialized, > then the event queue can be moved forward when the trace is > executed. Subsequently the rest of the system is unserialized and the > curTick is set the appropriate value. > > Ok. Maybe I didn't understand what's going on. There are two separate > issues. One is that you're planning to switch to the main event queue. The > other is that when executing the warm up trace, you need to advance the > simulator clock, right? Because of the second, you're expecting to advance > the clock to run the warmup trace and then put the clock back to the start > value. I'd like to suggest that you just advance the clock while running the > warmup trace and you leave it. If you reset statistics, nothing will ever > notice. I worry that advancing the clock and then moving it backwards in time > can cause some major problems. Actually you may still run into problems > because of other things that are scheduling events on the event queue (like > real time clock interrupts, device interrupts, etc.). > > Another option is to create a second event queue (which Steve has made > possible), run the warmup on that queue, and then switch Ruby to the main > queue and discard the warmup queue. > > Is there really no way to replay the warmup without advancing the clock? > This is the type of thing that atomic mode is good for. > > Nate > _______________________________________________ > 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
