On Jan 2, 2012, at 1:00 PM, Steve Reinhardt wrote: > I haven't actually looked at the code, but just for some context: > > - While it's true that classic caches can't checkpoint their state, Ruby > caches can, so that's what Nilay is trying to support. It's useful to have > checkpoints that include warmed cache state. I completely agree.
> > - Ali's argument makes sense about why we haven't cared (until now) to > generate checkpoints from anything other than atomic CPUs. However, it > doesn't explain why you wouldn't want to restore a checkpoint to a timing > CPU. In fact, it makes sense that you might want to start from a > checkpoint directly into timing mode to run an experiment (if you didn't > care about cache warmup, or wanted timing mode effects like prefetching to > be accounted for in your cache warmup). IIRC, early on there were bugs > with restoring an atomic CPU checkpoint directly into O3, and restoring > into atomic CPU followed by a switchover was just a workaround (probably > induced by a paper deadline). It really should be possible to restore a > checkpoint directly into any CPU model (including TimingSimpleCPU and O3). Yes, it would be nice to clean up all the cpu models so they can inter-checkpoint/restore. While I'm happy to see these changes made, I need to stress that we don't have regression tests for checkpointing/restore (ohh if I ever get time to work on a new regression system), and so we need to be extra diligent it making sure that any changes don't break existing functionality. Thanks, Ali > Steve > > On Mon, Jan 2, 2012 at 10:46 AM, Ali Saidi <[email protected]> wrote: > >> >> That isn't entirely correct. It assumes that if you're restoring from a >> checkpoint, it's with an atomic CPU. This is a reasonable assumption since >> it would just take longer to run with a timing or other CPU model and the >> classic memory system caches don't support checkpointing state. >> >> Ali >> >> On Jan 2, 2012, at 12:32 PM, Nilay Vaish wrote: >> >>> On Sun, 25 Dec 2011, Nilay Vaish wrote: >>> >>>> Looking at the function setCPUClass() in configs/common/Simulation.py, >> it seems like there is an assumption that checkpoints will always be >> created using atomic simple cpu. Is this true? Why do we need this? >>>> >>> >>> Any opinions on this? >>> >>> -- >>> Nilay >>> _______________________________________________ >>> 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 >> > _______________________________________________ > 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
