On Mon, 2 Jan 2012, Ali Saidi wrote:
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.
As of now, I am not too keen on this inter-cpu checkpoint restore. Let's
first start with restoring a checkpoint taken using TimingSimpleCPU or O3
to itself. So should we have a command line argument that specifies what
cpu to assume for restoring from the checkpoint?
--
Nilay
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
