You need to implement the following functions for the CPU. Taking a look at the simple timing CPU should be an easier way to grasp what must be done. Before the system can take a checkpoint, all the requests must be drained from it. drain() is called on each simobject which needs to respond if it has an outstanding request. If it does then it needs to stop issuing requests and wait for the current request to complete, calling the drain Event's process() method when this occurs. resume() is the opposite of drain() which means the system can continue issuing requests and acting as normal. serialize() needs to save all of the state the CPU needs to put itself in the same state as it was executing and unserialize() restores that saved state. Looking at other implementations of save()/restore() is the easiest way to do this. Finally, if you want to be able to switch to/from the inorder cpu switchOut() and takeOverFrom() need to be implemented.
Hope that helps, Ali On Feb 2, 2010, at 8:40 PM, Korey Sewell wrote: > Looks like we might need a "Checkpointing - Internals" page on the > wiki that summarizes this. > > I'm a little in the dark on what needs to be done myself... I assume > the main components for checkpointing would be serialize and > unserialize, but I guess traversing the function trace to/from those > functions would reveal more. Without any further documentation, I'd > probably try to GDB breakpoint in those functions and then figure > things out from there. > > Anyone with some thoughts and developmental "starter" advice here? > > > On Tue, Feb 2, 2010 at 2:20 PM, soumyaroop roy <s...@cse.usf.edu> > wrote: > Hello there, > > Could someone give me a quick overview on how to implement > checkpointing for inorder? I am not able to find any documentation for > it. So, I was trying to follow O3. But which methods - serialize(), > unserialize()? And what about cpu switching? > > regards, > Soumyaroop > > -- > Soumyaroop Roy > Ph.D. Candidate > Department of Computer Science and Engineering > University of South Florida, Tampa > http://www.csee.usf.edu/~sroy > _______________________________________________ > m5-dev mailing list > m5-dev@m5sim.org > http://m5sim.org/mailman/listinfo/m5-dev > > > > -- > - Korey > _______________________________________________ > m5-dev mailing list > m5-dev@m5sim.org > http://m5sim.org/mailman/listinfo/m5-dev _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
