Re: [PATCH 6/7] [RFC] Support multiply-bindable cgroup subsystems

[Li Zefan <lizf-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>]

Paul Menage wrote:
> On Tue, Mar 17, 2009 at 8:09 PM, Li Zefan <lizf-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org> wrote:
>> I don't see what's wrong with this behavior:
>>
>> multi subsys sits in rootnode if it's unbound, and is removed from
>> rootnode if it's binded at least in one hierarchy.
> 
> You mean just for the purposes of /proc/cgroup, or in reality?
> 

Yes, to show all subsystems in /proc/cgroup.

> Singleton (traditional) subsystems generally have some meaning outside
> of the cgroups framework, e.g. the "cpu" subsystem corresponds to CFS
> scheduler nodes for tasks; "cpuset" corresponds to the permitted
> cpus/mems for a task. For every task there's a single unique state
> object for each singleton subsystem.
> 
> But multi-bindable subsystems don't really have any meaning outside
> the cgroup framework, since there's no unique mapping from a task to
> its subsystem state. So instantiating a root cgroup object for that
> subsystem in the unbound hierarchy is a bit pointless - it can't
> really do anything. So it wouldn't really make sense to keep one
> instance of a multi-bindable subsystem attached to rootnote until the
> first bind for that subsystem, and then create fresh ones on the fly
> later if the subsystem is bound to more hierarchies. In particular,
> which one would you return to the rootnode later?
> 

For that purpose I suggest, we are not going to allocate a root cgroup
object for multi-subsys, but we just set the subsys-id in dump-root's
subsystem bits.

> But I guess we could just pretend in /proc/cgroup, and add a new
> column such as "multi-bindable".
> 
> Paul
> 
>