On Thu, Jun 23, 2011 at 11:10 AM, Beckmann, Brad <[email protected]>wrote:
> > 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. > Yes, the key point was to do it in the startup() phase rather than the unserialize() phase; the particular object the method is attached to is not that significant. > > > > 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. It should be easy to check that simulate(T-1) never returns before the outstanding transaction is complete. I don't think there's a need to check for a specific value of T (if that is what you're suggesting). Steve _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
