Re: [PATCH RFC cgroup/for-3.7] cgroup: mark subsystems with brokenhierarchy support and whine if cgroups are nested for them
From: Vivek Goyal
Date: Tue Sep 11 2012 - 10:57:14 EST
On Tue, Sep 11, 2012 at 10:51:06AM -0400, Vivek Goyal wrote:
> On Mon, Sep 10, 2012 at 03:31:25PM -0700, Tejun Heo wrote:
> > Currently, cgroup hierarchy support is a mess. cpu related subsystems
> > behave correctly - configuration, accounting and control on a parent
> > properly cover its children. blkio and freezer completely ignore
> > hierarchy and treat all cgroups as if they're directly under the root
> > cgroup. Others show yet different behaviors.
> > These differing interpretations of cgroup hierarchy make using cgroup
> > confusing and it impossible to co-mount controllers into the same
> > hierarchy and obtain sane behavior.
> > Eventually, we want full hierarchy support from all subsystems and
> > probably a unified hierarchy. Users using separate hierarchies
> > expecting completely different behaviors depending on the mounted
> > subsystem is deterimental to making any progress on this front.
> > This patch adds cgroup_subsys.broken_hierarchy and sets it to %true
> > for controllers which are lacking in hierarchy support. The goal of
> > this patch is two-fold.
> > * Move users away from using hierarchy on currently non-hierarchical
> > subsystems, so that implementing proper hierarchy support on those
> > doesn't surprise them.
> I know two current/potential users. systemd and libvirt. They are
> anyway going to create hierarchy irrespective of the fact whether
> controller supports it or not.
Just to be little precise here. AFAIK, systemd only mounts blkio
controller on a separate hiearchy but does not create child cgroups
under it. So all the services should still run in root cgroup.
For libvirt, I think by default they had enabled using blkio
controller and they were creating hiearchies under that for each
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/