From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Hansen Subject: Re: [PATCH 0/6] /proc/pid/checkpointable Date: Wed, 18 Mar 2009 07:42:51 -0700 Message-ID: <1237387371.8286.113.camel@nimitz> References: <20090317062754.GA2377@us.ibm.com> <20090317063940.GF2377@us.ibm.com> <49C0B6FF.5030104@cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <49C0B6FF.5030104-eQaUEPhvms7ENvBUuze7eA@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: Oren Laadan Cc: Containers , Sukadev Bhattiprolu List-Id: containers.vger.kernel.org On Wed, 2009-03-18 at 04:55 -0400, Oren Laadan wrote: Bhattiprolu wrote: > > From: Sukadev Bhattiprolu > > 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(). > > 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. I take it you didn't like the 'files' or 'uts' versions of this, either. Do we have a container object in the kernel that we could tag, anyway? > Second, what's wrong with doing a "dry" checkpoint on the container (or > if you prefer, the task, for what it's worth), that will not buffer nor > write out any data - just say "yes" or "no" ? > > (we could use a flag "CR_CTX_DRYRUN" when calling sys_checkpoint() for > this, and test for this flag in, say, kwrite/kread). > > After all, we don't expect applications or users to continuously and > repeatedly test if they can checkpoint, so it isn't performance critical. > So we simply reuse the existing code. Heh. Did you read Ingo's suggestions? He suggested *exactly* that. http://lkml.org/lkml/2008/10/9/196 > This would also catch cases where we can't checkpoint because the kernel > is low on memory - which wouldn't show up otherwise. > > And in any case, this is orthogonal to what Dave is pushing, following > Ingo's comment, to know when a task _becomes_ not-checkpointable. (And > in any case, I think our time is better spent on adding functionality > instead). > > Oren. -- Dave