On Sat, Jul 3, 2010 at 1:56 PM, soumyaroop roy <s...@cse.usf.edu> wrote: > Now, this is my understanding of how a checkpoint is taken. Please > correct me if I am wrong. I noted that when checkpointing is specified > with these options: "--take-checkpoint=N --at-instruction", the > max_insts_any_thread for the cpu is set to N which sets up a > termination event in the committed instructions queue, > comInstEventQueue (lets consider a uniprocessor and no > multithreading). After each instruction is retired the events from > this queue are serviced. So, when N instructions have been committed, > the drain() routine is called. The simulation is exited subsequently. > Then the writing of the checkpoint is directed by the python script, > Simulation.py. The serialize() routine should be called before the > simulation is exited, right?
Yes, via m5.checkpoint() > Also, the total number of retired > instructions can be more than N eventually, right? That wouldn't surprise me. > > Here is another observation which is a bit confusing to me. I traced > the routines that are called during O3's checkpointing and the > resume() routine is called when the checkpoint is taken (after drain() > and serialize() routines). Why is this happening? Since the checkpoint process drains the simulation (putting it in Drained mode), then you need to put it back in Running mode to continue simulation (basically ending the drain process). > Shouldn't resume() > be called while restoring from a checkpoint after the unserialize() > routine is called? It is; look for the need_resume variable in src/python/m5/simulate.py. Steve _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
