Re: [RFD] cgroup: about multiple hierarchies

[Vivek Goyal]

On Mon, Mar 12, 2012 at 03:28:17PM -0700, Tejun Heo wrote:
> Hey,
> 
> On Mon, Mar 12, 2012 at 11:22:18PM +0100, Peter Zijlstra wrote:
> > On Mon, 2012-03-12 at 15:10 -0700, Tejun Heo wrote:
> > > 
> > > * How to map controllers which aren't aware of full hierarchy is still
> > >   an open question but I'm still standing by one active node on any
> > >   root-to-leaf path w/ root group serving as the special rest group. 
> > 
> > What does this mean?
> 
> Let's say we have a tree like the following.
> 
>          root
>       /   |   \
>      G1  G2   G3
>              /  \
> 	   G31  G32
> 
> So, for cgroups which don't support full hierarchy, it'll be viewed as
> either,
> 
>          root
>       /   |   \
>      G1  G2   G3
> 
> or
> 
>           root
>       /   |   |  \
>      G1  G2  G31 G32
> 
> 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

One problem with above is that a children can create its own child cgroups
and compete at highest level for resources.

But same is the problem with second choice you gave. May be you are
thinking of introducing another knob to configure active point in the
path? I guess that will make cgroup configuration even harder.

May be we flatten the whole hierarchy. When we launch user sessions, we
don't give then permissions to create child cgroups for IO. For services
running with admin priviliges, we still don't have a good solution for
flat controllers. If nobody has a use case, I guess we just live with
that as that's the limitation of flat controller and one needs to make
it hierarchical, if need be.

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