[PATCH 0/6] /proc/pid/checkpointable
Serge E. Hallyn
serue at us.ibm.com
Wed Mar 18 10:18:40 PDT 2009
Quoting Oren Laadan (orenl at cs.columbia.edu):
> Serge E. Hallyn wrote:
> > Quoting Oren Laadan (orenl at cs.columbia.edu):
> >> Sukadev Bhattiprolu wrote:
> >>> From: Sukadev Bhattiprolu <sukadev at linux.vnet.ibm.com>
> >>> Date: Fri, 13 Mar 2009 17:25:42 -0700
> >>> Subject: [PATCH 5/6] Define and use proc_pid_checkpointable()
> >>> Create a proc file, /proc/pid/checkpointable, which shows '1' if
> >>> task is checkpointable and '0' if it is not.
> >>> To determine whether a task is checkpointable, the handler for this
> >>> new proc file, shares the same code with sys_checkpoint().
> > Hey Oren,
> > 3 counter-points:
> >> I still don't understand why we would like to do it this way.
> >> First, it makes little sense to do it per-task, because we are supposed
> >> to checkpoint an entire container.
> > Yes we need per-container info too. Actually, per-checkpoint-job-init,
> > so if we send pids in for that, it should return false if we send in the
> > pid of a task which isn't a proper checkpoint-job-init.
> > But we also want the info per-task, for debugging info.
> My suggestions works for this two: we add a flag CR_CTX_DRYRUN; a task
> can ask to checkpoint itself, or another task, with CR_CTX_DRYRUN and
> the checkpoint code runs without actual effect. (If we don't want to
> expose the actual flag to userspace, then we simply use it in an
> implementation of a /proc/PID/checkpointable operation).
Hmm, so if we pass in CR_CTX_DRYRUN, then the fd can point to a file
wherein to store a text represenation of the reason?
Dave will probably hate it, but it could be worse...
More information about the Containers