Re: Question about Vmadump

From: Paul H. Hargrove (PHHargrove_at_lbl_dot_gov)
Date: Wed Mar 10 2010 - 12:03:06 PST

  • Next message: G醔or R鮟zei: "BLCR: sleep process checkpointing problem"
    李宏亮 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 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     

  • Next message: G醔or R鮟zei: "BLCR: sleep process checkpointing problem"