Re: [RFC] cgroups: freezer -- Allow to attach a task to a frozencgroup

[Matt Helsley]

On Mon, Nov 28, 2011 at 08:08:44AM -0800, Tejun Heo wrote:
> On Mon, Nov 28, 2011 at 04:08:13PM +0400, Cyrill Gorcunov wrote:
> > In checkpoint/restore we need an ability to attach pids to
> > a frozen cgroup. Thus once pid reaches a frozen cgroup it is
> > not rejected, but the task get frozen immediately.

Frankly, I don't see the need for this. I think you should explain
it with more detail at the very least.

Why can't they be frozen before being checkpointed? Assuming you've
used SEIZE and spawned a new parasite thread, just move that thread to a 
cgroup for the parasitic threads then freeze the old cgroup.

> > 
> > Signed-off-by: Cyrill Gorcunov <gorcunov@xxxxxxxxxx>
> > ---
> > 
> > I would really appreciate complains and comments.
> 
> First of all, both freezer and cgroup have non-trivial pending
> patchsets (e.g. ->can_attach_task() is scheduled for removal) and I
> have changes which basically try to achieve about the same thing, so
> let's slow down a bit.  I think the problem is a bit more complex.
> 
> Some thoughts I have on cgroup freezer ATM,
> 
> * Currently, FROZEN -> FREEZING transition isn't possible.  That's why

No, IMO that would consitute breaking the interface. Scripts, tools,
applications, and tests have been written to rely on the fact that
the cgroup cannot go from FROZEN to FREEZING -- only from FROZEN to
THAWED.

>   event transition detection by polling is acceptable.  ie. once the
>   state is polled to be FROZEN, it stays frozen.  Allowing FREEZING ->
>   FROZEN transition would probably require improvements to state

(I'm assuming this last sentence has a thinko in it...)

>   transition notification too, at the very least, clarification of

Notification is a fine idea. However, not everything that's already
written expects them so correct usage of the cgroup freezer should not
require them -- IOW allowing the FROZEN -> FREEZING transition
isn't made OK just by adding notifications.

>   rules.
> 
> * There are some unclear corner cases and bugs the current cgroup
>   freezer has.  e.g. behavior w.r.t. kthreads is outright buggy.  It
>   would be great to figure out how to deal with them with or before
>   this change (ie. what happens when you transfer unfreezable
>   kthreads).

Huh? Shouldn't we just disable moving kthreads between cgroups? Allowing
userspace to freeze kthreads via cgroups seems like a *very* bad idea
(perhaps it's a thread critical for IO, or some driver, etc.).

Cheers
	-Matt Helsley

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/