Quoting Oren Laadan (orenl@xxxxxxxxxxxxxxx): > > > 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(). 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. I don't know how to represent those two cases, though. Also debugfs may be a more appropriate medium. > 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" ? You can't get a text explanation like 'fd 4 (/sys/class/net/eth0) is not checkpointable'. That's what's wrong with it. > (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. No, but we do expect someone trying to checkpoint their job and failing to be curious as to why. > 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). I think Suka's patch is small enough that there's not a lot of pursuing going on. Dave's may_checkpoint is a lot more ambitious. Just to be clear - are you saying you think both this patch and Dave's may_checkpoint patchsets ought to be delayed, or just Suka's, or just Dave's? :) -serge _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
