Paul Menage wrote: > On Tue, Mar 17, 2009 at 8:09 PM, Li Zefan <lizf@xxxxxxxxxxxxxx> 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 > > _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
