Thanks for creating the wiki page. I will populate it after I am done testing checkpoint restoration. Waiting for a resolution on the restoration issue.
regards, Soumyaroop On 2/8/10, Korey Sewell <ksew...@umich.edu> wrote: > > > Yes, that is absolutely correct! the list of instructions to be > > removed during a tick by the cleanUpRemovedInsts() routine comprises > > of both instructions that graduate and instructions that get squashed! > > And, cleanUpRemovedInsts() just removes the instruction schedule > > associated (and its register dependencies) by an instruction before > > removing it from "instList" (the global list of all instructions in > > flight in the pipeline). So, it appears ok to add the logic to drain > > the cpu here. Could you look into the cleanUpRemovedInsts() one more > > time? > > > OK, that looks right. The "removeList" kind of serves as the synchronizing > point > for all squashed and graduated instructions and that cleanUp function > traverses > that list. I was remarking on memory mgmt., but I forgot that those are > ref-counted > pointers (for the insts), so as soon as they are taken off the instruction > list they > should delete themselves. > > So after all the instructions are "cleaned" in that function, it looks safe > to add some drain logic > that will check all the per-thread global instruction lists and if they are > all empty then signal > the drain complete. > > > > > I was looking into the takeOverFrom() routine and it appears to > > involve a lot more work! But, I'll work on it later. > > > In the interim, checkpointing from/to the same cpu model is a proof of > concept and then switching > between models could be the next step. > > One last thing: If you get some time, can you add some details to the WIKI > about Checkpointing > for the InOrder model? This type of stuff gets lost in the development > process easily but if someone > just takes notes as they go along, then the next person who is interested in > checkpointing has a faster path to understanding > the code and eventually tweaking the process if need be (especially if that > next person is me :) ... ) > > I created a page there that we can edit as the solution gets panned out: > http://m5sim.org/wiki/index.php/InOrder. > > -- > - Korey > > _______________________________________________ > m5-dev mailing list > m5-dev@m5sim.org > http://m5sim.org/mailman/listinfo/m5-dev > > -- 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
