[lkml]   [2008]   [Oct]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 0/9] OpenVZ kernel based checkpointing/restart
    Quoting Oren Laadan (
    > Serge E. Hallyn wrote:
    > > Quoting Daniel Lezcano (
    > >> Oren Laadan wrote:
    > >>> Daniel Lezcano wrote:
    > >>>> Louis Rilling wrote:
    > >>>>> On Fri, Oct 17, 2008 at 04:33:03PM -0700, Dave Hansen wrote:
    > >>>>>> On Wed, 2008-09-03 at 14:57 +0400, Andrey Mirkin wrote:
    > >>>>>>> This patchset introduces kernel based checkpointing/restart as it is
    > >>>>>>> implemented in OpenVZ project. This patchset has limited functionality and
    > >>>>>>> are able to checkpoint/restart only single process. Recently Oren Laaden
    > >>>>>>> sent another kernel based implementation of checkpoint/restart. The main
    > >>>>>>> differences between this patchset and Oren's patchset are:
    > >>>>>> Hi Andrey,
    > >>>>>>
    > >>>>>> I'm curious what you want to happen with this patch set. Is there
    > >>>>>> something specific in Oren's set that deficient which you need
    > >>>>>> implemented? Are there some technical reasons you prefer this code?
    > >>>>> To be fair, and since (IIRC) the initial intent was to start with OpenVZ's
    > >>>>> approach, shouldn't Oren answer the same questions with respect to Andrey's
    > >>>>> patchset?
    > >>>>>
    > >>>>> I'm afraid that we are forgetting to take the best from both approaches...
    > >>>> I agree with Louis.
    > >>>>
    > >>>> I played with Oren's patchset and tryed to port it on x86_64. I was able
    > >>>> to sys_checkpoint/sys_restart but if you remove the restoring of the
    > >>>> general registers, the restart still works. I am not an expert on asm,
    > >>>> but my hypothesis is when we call sys_checkpoint the registers are saved
    > >>>> on the stack by the syscall and when we restore the memory of the
    > >>>> process, we restore the stack and the stacked registers are restored
    > >>>> when exiting the sys_restart. That make me feel there is an important
    > >>>> gap between external checkpoint and internal checkpoint.
    > >>> This is a misconception: my patches are not "internal checkpoint". My
    > >>> patches are basically "external checkpoint" by design, which *also*
    > >>> accommodates self-checkpointing (aka internal). The same holds for the
    > >>> restart. The implementation is demonstrated with "self-checkpoint" to
    > >>> avoid complicating things at this early stage of proof-of-concept.
    > >> Yep, I read your patchset :)
    > >>
    > >> I just want to clarify what we want to demonstrate with this patchset
    > >> for the proof-of-concept ? A self CR does not show what are the
    > >> complicate parts of the CR, we are just showing we can dump the memory
    > >> from the kernel and do setcontext/getcontext.
    > >>
    > >> We state at the container mini-summit on an approach:
    > >>
    > >> 1. Pre-dump
    > >> 2. Freeze the container
    > >> 3. Dump
    > >> 4. Thaw/Kill the container
    > >> 5. Post-dump
    > >>
    > >> We already have the freezer, and we can forget for now pre-dump and
    > >> post-dump.
    > >>
    > >> IMHO, for the proof-of-concept we should do a minimal CR (like you did),
    > >> but conforming with these 5 points, but that means we have to do an
    > >> external checkpoint.
    > >
    > > Right, Oren, iiuc you are insisting that 'external checkpoint' and
    > > 'multiple task checkpoint' are the same thing. But they aren't.
    > > Rather, I think that what we say is 'multiple tasks c/r' is what you say
    > > should be done from user-space :)
    > Then I don't explain myself clearly :)
    > The only thing I consider doing in user space is the creation of
    > the container, the namespaces and the processes.

    That I understand.

    > I argue that "external checkpoint of a single process" is very few
    > lines of code away from "self checkpoint" that is in v7.
    > I'm not sure how you define "external restart" ? eventually, the

    If I ever said external restart, I actually meant external checkpoint.
    I understand that a task should call sys_restart() itself.

    > processes restart themselves. It is a question of how the processes
    > are created to begin with.
    > >
    > > So particularly given that your patchset seems to be in good shape,
    > > I'd like to see external checkpoint explicitly supported. Please
    > > just call me a dunce if v7 already works for that.
    > >
    > It seems like you want a single process to checkpoint a single (other)
    > process, and then a single process to start a single (other) process.


    > I tried to explicitly avoid dealing with the container (user space ?
    > kernel space ?) and with creating new processes (user space ? kernel
    > space ?).

    And that's the right thing to do. But:

    > Nevertheless, it's the _same_ code. All that is needed is to make the

    I was under the impression that sys_checkpoint() on some other task's
    pid and then restarting with that image would fail right now.

    > checkpoint syscall refer to the other task instead of self, and the
    > restart should create a container and fork there, then call sys_restart.
    > I guess instead of repeating this argument over, I will go ahead and
    > post a patch on top of v7 to demonstrate this (without a container,

    Cool, thanks!

    > therefore without preserving the original pid).

    Yes, as i believe you said in another email earlier today, we have not
    decided about how to restore the pid. Eric continues to argue for
    playing games with /proc/sys/kernel/pid_max.


     \ /
      Last update: 2008-10-21 03:01    [W:0.030 / U:6.452 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site