> So here's the proposal: > > - Move all the magic into RubySystem::startup(), where we know that > all the Ruby objects have been unserialized (along with everything > else).
Currently, Ruby cache warmup is being handled as part of unserialization process (in Topology::unserialize). RubySystem::unserialize only clears the stats. It seems you are assuming that cache warmup and unserialization are two separate processes, am I right? If so, we should then move Ruby Cache warmup out of Topology::unserialize (e.g., to this new function (RubySystem::startup)). > - In RubySystem::startup(), we: > 1. Save the (already restored) curTick() value (call this T). > 2. For each transaction in the warm-up trace: > 2.1. Set curTick to 0. > 2.2. Inject the transaction. > 2.3. Call simulate(T-1) to run the transaction. The T-1 arg > will guarantee that we don't run past T. > 2.4. Call fatal() if the injected transaction doesn't complete > before T-1. > 3. Re-restore curTick to T. Is it possible to have unfinished already scheduled events when resetting curTick? if so, what would happen to them while we are playing with curTick? Thanks, Somayeh > Does this seem reasonable? > > Steve > > On Mon, Jun 20, 2011 at 5:23 PM, Beckmann, Brad <[email protected]> > wrote: >> 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 >> > _______________________________________________ > 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
