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
