Re: [PATCH v2 2/4] cgroup: Allow bypass mode in subtree_control

[Tejun Heo <tj@kernel.org>]

Hello, Waiman.

On Mon, Jul 24, 2017 at 02:20:59PM -0400, Waiman Long wrote:
> As said in patch 3, enabling bypass mode at subtree_control delegate the
> authority of enabling controllers to the children. The children own the
> resource control files directly. It will be more straight forward to

But that doesn't work at all because such child would end up
controlling the distribution of an ancestor's resources.  It breaks a
fundamental property of the hierarchy.

> explain if bypass mode can only be used consistently from the root down.
> Having a mix of regular enable and bypass down the tree will be more
> tricky to talk about.

Hmmm... it isn't just being tricky.  As proposed, it is in direct
conflict with the basic semantics of the resource hierarchy.

> > * While the idea is interesting, I think we need more concrete
> >   usecases to justify the addition and make sure that we aren't doing
> >   something misguided.  Can you please illustrate / give examples of
> >   how this would be useful?
> 
> Bypass mode targets mainly non-domain controllers and controllers that
> have cost associated with each additional level of hierarchy (e.g. cpu).
> I believe the end goal of cgroup v2 is to have all controllers migrated
> to it eventually. Consider the following:
> 
>     A
>    / \
>   B   C
>  / \ / \
> D  E F G
> 
> Controller X may want (A, B, C) to be controlled as one group with one
> set of control files whereas D, E, F, G will have their own control
> files. Controller Y may want all of them have their own control files.
> Bypass mode allows us to do that. With more and more controllers enabled
> in v2, the chance of this kind of configuration conflicts is going up.

I think I understand what it wants to do but I think it's still
lacking justfications given how invasive the change is to the basic
operation and usage.  We need more than one can think of this and it
can help with certain hypothetical use cases.  ie. along the line of
what the actual use cases are, what our overhead looks like and why,
and why the problem can't be solved in a different, hopefully less
intrusive, way.

Thanks.

-- 
tejun