Sukadev Bhattiprolu wrote: > From: Sukadev Bhattiprolu <sukadev@xxxxxxxxxxxxxxxxxx> > 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. 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. 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. _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers