lkml.org 
[lkml]   [2008]   [Oct]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC][PATCH 1/2] Track in-kernel when we expect checkpoint/restart to work


    Daniel Lezcano wrote:
    > Greg Kurz wrote:
    >> On Thu, 2008-10-09 at 12:04 -0700, Dave Hansen wrote:
    >>> Suggested by Ingo.
    >>>
    >>> Checkpoint/restart is going to be a long effort to get things working.
    >>> We're going to have a lot of things that we know just don't work for
    >>> a long time. That doesn't mean that it will be useless, it just means
    >>> that there's some complicated features that we are going to have to
    >>> work incrementally to fix.
    >>>
    >>> This patch introduces a new mechanism to help the checkpoint/restart
    >>> developers. A new function pair: task/process_deny_checkpoint() is
    >>> created. When called, these tell the kernel that we *know* that the
    >>> process has performed some activity that will keep it from being
    >>> properly checkpointed.
    >>>
    >>> The 'flag' is an atomic_t for now so that we can have some level
    >>> of atomicity and make sure to only warn once.
    >>>
    >>> For now, this is a one-way trip. Once a process is no longer
    >>> 'may_checkpoint' capable, neither it nor its children ever will be.
    >>> This can, of course, be fixed up in the future. We might want to
    >>> reset the flag when a new pid namespace is created, for instance.
    >>>
    >> Then this patch should be described as:
    >>
    >> Track in-kernel when we expect checkpoint/restart to fail.
    >>
    >> By the way, why don't you introduce the reverse operation ?
    >
    > I think implementing the reverse operation will be a nightmare, IMHO it
    > is safe to say we deny checkpointing for the process life-cycle either
    > if the created resource was destroyed before we initiate the checkpoint.
    >
    > For example, you create a socket, the process becomes uncheckpointable,
    > you close (via sys_close) the socket, you have to track this close to be
    > related to the socket which made the process uncheckpointable in order
    > to make the operation reversible.

    I agree that it makes sense to only track transitions in one direction.
    Therefore at any given point in time all we'll know is that the process
    "may be non-checkpointable", instead of the clear-cut "uncheckpointable"
    (webster anyone ?).

    The distinction is important, because it may be that the process is,
    after all, checkpointable, so users/developers could still try to
    perform a checkpoint, should they wish too. The only thing is that
    it is not guaranteed to succeed.

    In fact, one way to transition back to the "checkpointable" state is
    by doing a dry-checkpoint, where no data is saved (/dev/null ?). No
    side effects will occur except for a short downtime due to the freeze
    period. If the dry-checkpoint completes successfully - we can reset
    the non-/un-/not-/a-/dis-checkpointable flag.

    >
    > Let's imagine you implement this reverse operation anyway, you have a
    > process which creates a TCP connection, writes data and close the socket
    > (so you are again checkpointable), but in the namespace there is the
    > orphan socket which is not checkpointable yet and you missed this case.
    > _______________________________________________
    > Containers mailing list
    > Containers@lists.linux-foundation.org
    > https://lists.linux-foundation.org/mailman/listinfo/containers

    Oren.


    \
     
     \ /
      Last update: 2008-10-10 12:15    [W:4.126 / U:0.056 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site