LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "Serge E. Hallyn" <serue@us.ibm.com>
To: Dave Hansen <dave@linux.vnet.ibm.com>
Cc: Oren Laadan <orenl@cs.columbia.edu>,
linux-api@vger.kernel.org, containers@lists.linux-foundation.org,
mingo@elte.hu, linux-kernel@vger.kernel.org,
Peter Chubb <peterc@gelato.unsw.edu.au>,
linux-mm@kvack.org, hpa@zytor.com,
Andrew Morton <akpm@linux-foundation.org>,
torvalds@linux-foundation.org, tglx@linutronix.de,
viro@zeniv.linux.org.uk
Subject: Re: [RFC v7][PATCH 2/9] General infrastructure for checkpoint restart
Date: Tue, 28 Oct 2008 13:33:22 -0500 [thread overview]
Message-ID: <20081028183322.GA13684@us.ibm.com> (raw)
In-Reply-To: <1225145373.12673.125.camel@nimitz>
Quoting Dave Hansen (dave@linux.vnet.ibm.com):
> On Mon, 2008-10-27 at 17:51 -0400, Oren Laadan wrote:
> > > Instead, how about a flag to sys_checkpoint() -- DO_RISKY_CHECKPOINT --
> > > which checkpoints despite !may_checkpoint?
> >
> > I also agree with Matt - so we have a quorum :)
> >
> > so just to clarify: sys_checkpoint() is to fail (with what error ?) if the
> > deny-checkpoint test fails.
> >
> > however, if the user is risky, she can specify CR_CHECKPOINT_RISKY to force
> > an attempt to checkpoint as is.
>
> This sounds like an awful lot of policy to determine *inside* the
> kernel. Everybody is going to have a different definition of risky, so
> this scheme will work for approximately 5 minutes until it gets
> patched. :)
>
> Is it possible to enhance our interface such that users might have some
> kind of choice on these matters?
Well we could always just add a field to /proc/self/status, and let
userspace check that field (after freezing the task) for the
presence of CR_CHECKPOINT_RISKY and make up its own mind.
Though my preference is for simplicity - just refuse the checkpoint.
That way people might screan loudly enough for us to support the
features they want. If we let them just bypass and hope for the
best that starts to dilute some of the intended effect of all this.
-serge
next prev parent reply other threads:[~2008-10-28 18:43 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-20 5:40 [RFC v7][PATCH 0/9] Kernel based checkpoint/restart Oren Laadan
2008-10-20 5:40 ` [RFC v7][PATCH 1/9] Create syscalls: sys_checkpoint, sys_restart Oren Laadan
2008-10-20 5:40 ` [RFC v7][PATCH 2/9] General infrastructure for checkpoint restart Oren Laadan
2008-10-21 19:41 ` Andrew Morton
2008-10-21 20:24 ` Serge E. Hallyn
2008-10-21 20:41 ` Andrew Morton
2008-10-22 1:33 ` Oren Laadan
2008-10-22 2:55 ` Daniel Jacobowitz
2008-10-22 3:02 ` Dave Hansen
2008-10-22 14:29 ` Daniel Jacobowitz
2008-10-22 15:28 ` Serge E. Hallyn
2008-10-22 16:02 ` Oren Laadan
2008-10-22 17:03 ` Serge E. Hallyn
2008-10-22 18:32 ` Oren Laadan
2008-10-27 8:27 ` Peter Chubb
2008-10-27 11:03 ` Oren Laadan
2008-10-27 16:42 ` Dave Hansen
2008-10-27 17:11 ` Oren Laadan
2008-10-27 20:51 ` Matt Helsley
2008-10-27 21:20 ` Serge E. Hallyn
2008-10-27 21:51 ` Oren Laadan
2008-10-27 22:09 ` Dave Hansen
2008-10-28 18:33 ` Serge E. Hallyn [this message]
2008-10-20 5:40 ` [RFC v7][PATCH 3/9] x86 support for checkpoint/restart Oren Laadan
2008-10-20 5:40 ` [RFC v7][PATCH 4/9] Dump memory address space Oren Laadan
2008-10-20 5:40 ` [RFC v7][PATCH 5/9] Restore " Oren Laadan
2008-10-20 5:40 ` [RFC v7][PATCH 6/9] Checkpoint/restart: initial documentation Oren Laadan
2008-10-28 16:48 ` Michael Kerrisk
2008-10-20 5:40 ` [RFC v7][PATCH 7/9] Infrastructure for shared objects Oren Laadan
2008-10-20 5:40 ` [RFC v7][PATCH 8/9] Dump open file descriptors Oren Laadan
2008-10-20 5:40 ` [RFC v7][PATCH 9/9] Restore open file descriprtors Oren Laadan
2008-10-21 19:21 ` [RFC v7][PATCH 0/9] Kernel based checkpoint/restart Andrew Morton
2008-10-21 20:41 ` Dave Hansen
2008-10-22 9:20 ` Ingo Molnar
2008-10-22 11:51 ` Daniel Lezcano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20081028183322.GA13684@us.ibm.com \
--to=serue@us.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=containers@lists.linux-foundation.org \
--cc=dave@linux.vnet.ibm.com \
--cc=hpa@zytor.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mingo@elte.hu \
--cc=orenl@cs.columbia.edu \
--cc=peterc@gelato.unsw.edu.au \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=viro@zeniv.linux.org.uk \
--subject='Re: [RFC v7][PATCH 2/9] General infrastructure for checkpoint restart' \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).