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.
- 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). 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
