Hi Somayeh, Comments below:
> -----Original Message----- > From: [email protected] [mailto:[email protected]] > Sent: Wednesday, June 22, 2011 7:26 PM > To: Steve Reinhardt; gem5 Developer List > Cc: Beckmann, Brad > Subject: Re: [gem5-dev] [m5-dev] Ruby Cache Warmup > > > 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)). > Implementing cache warmup replay in the RubySystem::startup function is not necessary. Since the Topology is also a SimOjbect and already has access to the necessary sequencer pointers, it is probably easier to implement cache warmup in the Topology::startup function. That is fine by me. > > - 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? > Assuming that you are resetting the curTick to an earlier tick, then all events scheduled during the unserialize phase should not be executed during the startup phase. The key is that we need to make sure that a cache warmup request and all its side effects are completed in T-1 ticks. As long as T >= 100000, I suspect we'll be fine, but we should verify that. Brad _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
