From: Paul H. Hargrove (PHHargrove_at_lbl_dot_gov)
Date: Wed Mar 10 2010 - 12:03:06 PST
����� wrote: > > Hello Professor: > > Haven't contact with you for a long time, I hope everything about you > is fine > > I 've got a question about the use of Vmadump when checkpointing and > restarting. > > when checkpointing a process, Vmadump help to dump the virtual address > space of the process to the file on the disk, But before we restart > the process, The dumped vitual address space now maybe mapped for > other use, Maybe a read-only file, or other devices or for other use. > I mean that vm area is not avaliable or only partially available for > restoring. Can this scene happen? if yes, How can Vmadump restore the > process address space�� > > > There are two ways I could understand your question. So I'll try to answer them both: If at restart time a mmap()ed file or device is missing, or if the permissions do not permit restoring the original type of access, then the restart will fail with information about what file is causing the problem. We are able to handle the special case of files that were already unlinked at the time the checkpoint was taken (something often done for temporary files) by storing the file contents in the checkpoint context file. At restart time the process fork()ed by the cr_restart code will run code in VMAdump that removes all of that processes mappings before restoring any from the context file. This even includes unmapping the original stack and executable, which is only possible because this is done in the kernel. Additionally, the work done in VMAdump allows a 32-bit process to restore a 64-bit one. So, it cannot happen that some portion of the address space of the "target" process is unavailable. -Paul -- Paul H. Hargrove PHHargrove_at_lbl_dot_gov Future Technologies Group Tel: +1-510-495-2352 HPC Research Department Fax: +1-510-486-6900 Lawrence Berkeley National Laboratory