[lkml]   [2011]   [Apr]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 05/10] Core checkpoint/restart support code

    On 04/04/2011 12:27 PM, Serge E. Hallyn wrote:
    > Quoting Nathan Lynch (
    >> On Mon, 2011-04-04 at 10:10 -0500, Serge E. Hallyn wrote:
    >>> Quoting Nathan Lynch (
    >>>> On Sun, 2011-04-03 at 14:03 -0500, Serge E. Hallyn wrote:
    >>>>> Quoting (
    >>>>>> Only a pid namespace init task - the child process produced by a call
    >>>>>> to clone(2) with CLONE_NEWPID - is allowed to call these. The state
    >>>>> So you make this useful for your cases by only using this with
    >>>>> application containers - created using lxc-execute, or, more precisely,
    >>>>> using lxc-init as the container's init. So a container running a stock
    >>>>> distro can't be checkpointed.
    >>>> Correct, a conventional distro init won't work, and application
    >>>> containers are my focus for now, at least.
    >>>>> Is this just to keep the patch simple for now, or is there some reason
    >>>>> to keep this limitation in place?
    >>>> I guess you're asking whether non-pid-init processes could be allowed to
    >>>> use the syscalls?
    >>> No. I'm asking whether you are intending to later on change the checkpoint
    >>> API to allow an external task to checkpoint a pid-init process, rather than
    >>> the pid-init process having to initiate it itself.
    >> No, that is not the intention. I can see how that would be problematic
    >> for those wanting to run minimally-modified distro containers, but I
    >> think running a patched pid-init is a reasonable tradeoff to ask users
    >> to make in order to get c/r. And there's nothing to keep the standard
    >> distro inits from growing c/r capability.
    > It's not necessarily a dealbreaker, since presumably I can hack the
    > needed support into upstart, triggered by a boot option so it isn't
    > activated on a host. But especially given the lack of interest in
    > this thread so far, I don't see a point in pushing this, an API-incompatible
    > less-capable version of the linux-cr tree. If it can gain traction
    > better than linux-cr, that'd be one thing. But given the amount of
    > review and testing the other tree has gotten - and I realize you're
    > able to piggy-back on much of that - and, again, the lack of responses
    > so far, I just don't see this as worth pushing for.

    First, thanks to Nathan for cleaning up and re-producing a "minimal"
    patchest for review.

    From the technical point of view it *is* a big problem: there are
    very good reasons why we chose a certain design.

    If Natahan is suggesting in-kernel tree creation as a temporary thing
    to simplify the code for review - then, given that this patch handles
    a single process, doing so add lots of unnecessary code, all of which
    in the kernel.

    If this is the beginning of a permanent approach, then it is totally
    incompatible with what we have done so far, and severely restricts
    the kind of use--cases of the project, potentially making it too
    unattractive for many natural adaptors, like HPC users. Sorry, nack.



     \ /
      Last update: 2011-04-04 20:05    [W:0.026 / U:1.360 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site