Re: [RFD] cgroup: about multiple hierarchies

[James Bottomley]

On Tue, 2012-03-13 at 08:59 -0700, Tejun Heo wrote:
> Hey, Vivek.
> 
> On Tue, Mar 13, 2012 at 10:03:45AM -0400, Vivek Goyal wrote:
> > > With root being treated specially, probably as just being a equal
> > > group as other groups, I'm not fully determined about that yet.
> > 
> > So what wrong with flattening the whole hierarchy and all groups being active
> > in the path? It is not worse then second option?
> > 
> >              root
> >        /   |  |  |  \
> >       G1  G2  G3 G31 G32
> 
> It is worse because while there isn't much need for orthogonal
> hierarchies, people often need to apply different limits at different
> levels of the hierarchy for different controllers.  ie. it often
> happens that the distinction between G31 and G32 matters for one
> controller but not for others.  The problem with flattening like you
> suggested above is that it isn't a hierarchy at all - membership isn't
> recursive.
> 
> Imposing limits at single level is an additional restriction and may
> cause some config complexity but it'll be at least explicit and can
> co-exist with full hierarchy in meaningful way.

Isn't there a simple fix for this?  Each controller can decide whether
to pay attention to its cgroup parent in calculating the resource limits
or counting usage.  If the controller elects not to pay attention to its
parents when counting resources and enforcing limits, it effectively
gives you a flat hierarchy from the point of view of the controller.

What actually happens depends on how the controller calculates the
limits: if it's a global fraction, then it's completely flat, if it's
just an absolute limit, then it wouldn't pay attention to the parent
anyway, if it's a proportion, then the controller has to decide how to
divide up the parent's allocation.

James


--
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/