[PATCH 6/7] [RFC] Support multiply-bindable cgroup subsystems
menage at google.com
Tue Mar 31 02:02:05 PDT 2009
On Tue, Mar 17, 2009 at 8:09 PM, Li Zefan <lizf at cn.fujitsu.com> 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?
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?
But I guess we could just pretend in /proc/cgroup, and add a new
column such as "multi-bindable".
More information about the Containers