Brad, 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.
What if T is not large enough to finish cache warmup? do we need to stop other scheduled events?! In addition, based on Steve's suggestion, We should move cache warmup to startup stage (e.g., from Topology::unserialize to Topology::startup), which we know the unserialization is done and curTick value is set. I think startup phase is the right place to initialize these events. What do you think? Thanks, Somayeh > No, I wasn't suggesting that we explicitly check that T is a certain > value. Instead, I was trying to suggest that we need to implement some > sort of checker in the event queue and not just rely on our intuition that > this should always work. In particular, I am imagining when resetting the > event queue to tick 0 we can put it in a mode where it checks that all > events scheduled are for ticks T-1 or less. Then when simulate(T-1) is > reached, we take the event queue out of this checker mode. That should > catch any cache warmup side effects impacting the main execution. > > Brad > > >> >> 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). > > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
