lkml.org 
[lkml]   [2017]   [Jul]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCHSET for-4.13] cgroup: implement cgroup2 thread mode, v2
On Tue, Jul 11, 2017 at 10:14:42AM -0400, Waiman Long wrote:

> The "join" was a special op for the children of cgroup root to join the
> root as part of a threaded subtree. The children can instead use the
> "enable" option to become a thread root which was the configuration
> shown above. This behavior applied only to children of root. Down the
> hierarchy, you can't have configuration like:
>
> R (t=0)
> / \
> D (t=1)
> / \
> T D (t=1)

Why not?

First you create:

R (t=0)
/ \
D (t=1)
/ \
T T (t=1)

Then you flip t=0 like:

R (t=0)
/ \
D (t=1)
/ \
T D (t=0)

And then you flip t=1 again:

R (t=0)
/ \
D (t=1)
/ \
T D (t=1)

> With Tejun's v3 patch, the "join" operation was removed and "enable"

I've no clue what 'enable' is... :-(

> behaved like "join" in joining the threaded subtree of the root. I was
> wrong in saying that the configuration listed in your example was not
> possible. It was, but it depends on the order of activating the thread
> mode. If we enables thread mode on a child of root first followed by the
> root itself, we can have your configuration, but not in the reverse
> order. It was possible in the reverse order in the previous patch.

Just create a T child, then flip t=0 to convert it to D, then flip it to
1 again to create a new thread-root, no?

> > And this is detection by inference, which breaks the moment you disable
> > all resource domain controllers, because at that point those files will
> > not be present.
>
> It is true that there is no external marker to find out if a threaded
> cgroup is a root or not when the parent of a thread root is also a
> thread root of a separate threaded subtree if the domain controller
> files are not present. However, we can always add a status file to
> indicate the state of threaded-ness of a cgroup if we want to.

Why add status files when a simple change in marker can readily provide
this information?

> Tejun's patch makes resource domain the default and threaded-ness as an
> additional attribute that needs to be specified. Your proposal make
> non-resource domain where threads can exist as the default and resource
> domain as something that needs to be explicitly specified.

Not so. My proposal has resource domains as the default (remember, root
_MUST_ be a resource domain, therefore we must start start with
root.d=1). Therefore, any new subgroup will be a resource domain by
default and if you ignore the new attribute it will work exactly like
cgroup-v2 does today.

Only if you clear the new attribute do you get a thread subgroup.

> They are just
> different ways of partitioning a cgroup hierarchy into different
> domains. Tejun's patch has a well defined boundary for threaded subtree
> where threads can be migrated from one part of a subtree to another.
> Your proposal is less clear-cut on how to handle thread migration.

Disagree again. We have the exact same boundaries. Just ensure the
migration doesn't escape the resource domain.

\
 
 \ /
  Last update: 2017-07-11 18:53    [W:0.106 / U:0.532 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site