Yes, running in startup() guarantees that all the Ruby objects are unserialized before we run the trace without having to force some order of unserialization.
Steve On Fri, Jun 24, 2011 at 11:42 AM, Beckmann, Brad <[email protected]>wrote: > By the way, if Somayeh implements the latest proposal, is there any benefit > running the trace during startup versus unserialize? I don't see one, but > maybe I'm missing something. > > Brad > > > > -----Original Message----- > > From: [email protected] [mailto:gem5-dev- > > [email protected]] On Behalf Of Beckmann, Brad > > Sent: Friday, June 24, 2011 11:25 AM > > To: Steve Reinhardt > > Cc: gem5 Developer List > > Subject: Re: [gem5-dev] [m5-dev] Ruby Cache Warmup > > > > Thanks Steve. > > > > Your latest suggestion is very similar to how the current patch works. > The > > only difference is that the Ruby event queue shim layer does a logical > pointer > > swap and not a physical pointer swap within the main gem5 event queue > > itself. I'm somewhat leery of making the event queue head pointer > public, > > but if you're ok with it, then I'll go along with it. It certainly will > be less work > > for Somayeh...no need to worry about events scheduling past T-1 ticks, > etc. > > > > Does that all make sense to you Somayeh? > > > > Brad > > > > > > From: Steve Reinhardt [mailto:[email protected]] > > Sent: Friday, June 24, 2011 10:07 AM > > To: Beckmann, Brad > > Cc: [email protected]; gem5 Developer List > > Subject: Re: [gem5-dev] [m5-dev] Ruby Cache Warmup > > > > > > On Fri, Jun 24, 2011 at 9:16 AM, Beckmann, Brad > > <[email protected]<mailto:[email protected]>> wrote: > > Hi Somayeh, > > > > Thanks for the questions. We definitely want to make sure we're all on > the > > same page before we start coding. My answers are below: > > > > > why do you think we need to ensure that there is no event scheduled > > > for ticks T or more? We only need to make sure all Ruby cache warmup > > > events are done before T regardless of what have been scheduled for > after > > that. > > Sorry for the confusion. You are right that other events may be > scheduled > > for ticks T or more. In particular, during the unserialization phase, I > suspect > > several events will be placed on the event queue for tick T or more. > There > > may even be other events put on the event queue for tick T or more during > > other SimObjects' startup routines. The key is that we should make sure > > during the cache warmup phase (within Topology::startup) that all events > > scheduled are for ticks T-1 or less. > > > > > What if T is not large enough to finish cache warmup? do we need to > > > stop other scheduled events?! > > We need to call fatal and return a description that T is not large enough > > (include the value of T in the error message). > > > > I agree with what Brad is saying, but just to be crystal clear on the > > mechanism: I believe that resetting curTick to 0 and calling > simulate(T-1) > > should be adequate, as it will force us out of the simulation loop at T-1 > > whether or not the Ruby transaction is complete. If we hit T-1 and the > > transaction is not complete, then we can call fatal. As long as there > are no > > Ruby components that schedule events past the completion of a > transaction, > > this should be safe. If there is a chance that additional events could > be > > scheduled (e.g., replacement writebacks?) then we would need to have a > > way to check that Ruby is completely idle at T-1. > > > > I think it would be awkward to have a mode where we test every event > > that's scheduled to make sure it doesn't have a timestamp that goes past > T. > > If we decide that something like that is really necessary, then I might > > consider switching to Nate's idea of just using a separate event queue. > > Another possibility that might be a little easier to code than having to > walk all > > of the Ruby objects and switch their event queue pointer would be to > > temporarily move the existing events out of the way, then restore them at > > the end. Hmm, now that I said that, that sounds pretty appealing... it's > easy > > to do since the event queue is basically a linked list (just save the > head > > pointer somewhere and replace it with NULL). How's this for another > option > > (still called from someone's startup() method): > > > > 1. Save the (already restored) curTick() value (call this T). > > 2. Save the event queue head pointer value, replace with NULL (will > need > > to add an EventQueue method for this, since head is private). > > 3. Set curTick to 0 (optional, but might be useful even if just to > make it > > obvious that this isn't the real simulation) > > 4. Schedule and event to inject the first transaction at time 0 (or T > if we > > didn't reset curTick, or maybe just inject it directly?) > > 5. Call simulate() > > 5.1. In the callback function as each transaction completes, > inject the > > next transaction. > > 5.2. When there are no more transactions, either call > exitSimLoop() > > directly or just wait for the MAXINT event that simulate() schedules to > kick us > > out of the loop. (I think the latter is safer, since it guarantees that > any trailing > > events like writebacks will complete.) > > 6. Restore event queue head pointer. > > 7. Re-restore curTick to T. > > > > Thoughts? > > > > Steve > > _______________________________________________ > > 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
