On Jul 4, 2010, at 6:44 PM, soumyaroop roy wrote: > On Sun, Jul 4, 2010 at 5:24 PM, Korey Sewell <[email protected]> wrote: > >> >> Also, >> Even without the caches being checkpointed (and subsequently warmed up), >> wouldnt checkpointing still be useful to the degree that at least you have >> the memory and CPU state to some point way down along in your simulation? So >> if you're interested in something say some billion of cycles down the >> simulation there would still be some benefit of not having to simulate that >> X billion cycles and warming up from that point instead of the program >> origin (assuming that SimPoints or whatever workload approximation isnt >> applicable). > > Right, unless it is possible to take a checkpoint with a simple cpu > and then restore with the inorder cpu. In fact, that brings up my next > question. How does switching cpu work in conjunction with > checkpointing? Is it possible to take a checkpoint with a simple cpu > (old cpu) and then restore from that checkpoint directly into another > cpu (new cpu)? Or does the restoration from the checkpoint resume into > the old cpu, switches out the old cpu and then calls the take over > routine for the new cpu? It looks like that it is the latter case. > However, if the former can also be done (and is permissible), then I'd > implement the switchover routine, takeOverFrom(), for inorder and go > from there. That would reveal if the bug is indeed in the resume part > of the inorder code or not. You have to restore into the original CPU, but you only need to be in that state for 1 cycle (or perhaps even not) before you call switch CPU.
Ali _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
