Re: [PATCH 07/10] cgroup: implement cgroup v2 thread support

[Tejun Heo <tj@kernel.org>]

Hello, Waiman.

On Mon, Jun 12, 2017 at 11:41:09AM -0400, Waiman Long wrote:
> > Internally, in a threaded subtree, each css_set has its ->proc_cset
> > pointing to a matching css_set which belongs to the thread root.  This
> > ensures that thread root level cgroup_subsys_state for all threaded
> > controllers are readily accessible for domain-level operations.
>
> As far as I understand, the proc_cset thing is just for cgroup.procs
> iteration purpose. They are not used for accessing cgroup_subsys_state
> for domain-level operation.  In fact, all the relevant CSSes will be
> available in the local css_set and there is no need to look elsewhere.

Because none is implementing domain resource accounting.  Once we
start doing that, we'll have to charge them against domain csses not
the thread ones.

> > +/* if threaded, would @cgrp become root of a mixed threaded subtree? */
> > +static bool cgroup_is_mixable(struct cgroup *cgrp)
> > +{
> > +	/*
> > +	 * Root isn't under domain level resource control exempting it from
> > +	 * the no-internal-process constraint, so it can serve as a thread
> > +	 * root and a parent of resource domains at the same time.
> > +	 */
> > +	return !cgroup_parent(cgrp);
> > +}
> 
> Eventually, I would like to see a container root to be regarded as
> mixable so that it will look and feel like a real root to the container.
> Yes, that will mean having to deal with internal process competition
> with resource domain controllers. If we are going to keep the no
> internal process constraint, this is the other exception that I would
> like to have. We can work around that by having, for example, special
> directory for resource domain controllers to manage their resources like
> what I have proposed in the resource domain patch. Or we can just let
> those resource domain controllers to deal with it.

Yeah, the code and semantics are structured for future expansion.
That said, such expansion has to mean something inherently useful.  Up
until now, all that have been suggested are either cosmetic or not
clearly defined and IMHO do more to obscure what's going on rather
than enable anything fundamental.  What we do with the interface
should follow the function.  If we can come up with a way to lift the
restriction on an internal node which enables some fundamental
capabilities in a clearly defined manner, let's of course do that, but
we shouldn't do that just because we feel like to.

Thanks.

-- 
tejun