> The solution that Somayeh is working on will allow us to remove the ruby > event queue API. Ruby already uses the main event queue underneath for all > operations except cache warmup. When executing a warmup trace, the event > queue must move forward. If Ruby is the first SimObject unserialized, then > the event queue can be moved forward when the trace is executed. > Subsequently the rest of the system is unserialized and the curTick is set > the appropriate value.
Ok. Maybe I didn't understand what's going on. There are two separate issues. One is that you're planning to switch to the main event queue. The other is that when executing the warm up trace, you need to advance the simulator clock, right? Because of the second, you're expecting to advance the clock to run the warmup trace and then put the clock back to the start value. I'd like to suggest that you just advance the clock while running the warmup trace and you leave it. If you reset statistics, nothing will ever notice. I worry that advancing the clock and then moving it backwards in time can cause some major problems. Actually you may still run into problems because of other things that are scheduling events on the event queue (like real time clock interrupts, device interrupts, etc.). Another option is to create a second event queue (which Steve has made possible), run the warmup on that queue, and then switch Ruby to the main queue and discard the warmup queue. Is there really no way to replay the warmup without advancing the clock? This is the type of thing that atomic mode is good for. Nate _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
