Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1684049 > unrolled thread

Re: [PATCHSET for-4.13] cgroup: implement cgroup2 thread mode, v2

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCHSET for-4.13] cgroup: implement cgroup2 thread mode, v2 Peter Zijlstra <peterz@infradead.org> - 2017-07-10 10:40 +0200
    Re: [PATCHSET for-4.13] cgroup: implement cgroup2 thread mode, v2 Waiman Long <longman@redhat.com> - 2017-07-10 23:10 +0200
      Re: [PATCHSET for-4.13] cgroup: implement cgroup2 thread mode, v2 Peter Zijlstra <peterz@infradead.org> - 2017-07-11 14:20 +0200
        Re: [PATCHSET for-4.13] cgroup: implement cgroup2 thread mode, v2 Waiman Long <longman@redhat.com> - 2017-07-11 16:20 +0200
          Re: [PATCHSET for-4.13] cgroup: implement cgroup2 thread mode, v2 Peter Zijlstra <peterz@infradead.org> - 2017-07-11 19:00 +0200
            Re: [PATCHSET for-4.13] cgroup: implement cgroup2 thread mode, v2 Waiman Long <longman@redhat.com> - 2017-07-11 23:20 +0200
              Re: [PATCHSET for-4.13] cgroup: implement cgroup2 thread mode, v2 Peter Zijlstra <peterz@infradead.org> - 2017-07-12 09:50 +0200
                Re: [PATCHSET for-4.13] cgroup: implement cgroup2 thread mode, v2 Waiman Long <longman@redhat.com> - 2017-07-12 16:10 +0200

#1684049 — Re: [PATCHSET for-4.13] cgroup: implement cgroup2 thread mode, v2

On Fri, Jun 30, 2017 at 09:23:24AM -0400, Tejun Heo wrote:
> On Tue, Jun 27, 2017 at 09:01:43AM +0200, Peter Zijlstra wrote:
> > On Mon, Jun 12, 2017 at 05:27:53PM -0400, Tejun Heo wrote:

> > IIRC the problem with the 'threaded' marker is that it doesn't clearly
> > capture what a resource domain is.
> > 
> > That is, assuming that a thread root is always a resource domain, we get
> > the following problem:
> > 
> > If we set 'threaded' on the root group in order to create a thread
> > (sub)group. If we then want to create another domain group, we'd have to
> > clear 'threaded' on that.
> > 
> > 	R (t=1)
> >        / \
> > (t=1) T   D (t=0)
> > 
> > So far so good. However, now we want to create another thread group
> > under our domain group D, so we have to set its 'threaded' marker again:
> > 
> > 	R (t=1)
> >        / \
> > (t=1) T   D (t=1)
> >          /
> > 	T (t=1)
> > 
> > And we can no longer identify D as a resource domain. If OTOH we mark
> > 'domain' we get:
> > 
> > 	R (d=1)
> >        / \
> > (d=0) T   D (d=1)
> >          /
> > 	T (d=0)
> > 
> > Which clearly identifies the domains and the thread only groups.
> 
> So, the difference between the two interfaces is that the one I
> proposed is marking the thread root which makes all its descendants
> threaded while the above is marking each individual cgroup as being
> whether a resource domain or threaded.

You start by marking the thread root, but then continue to mark all
'threaded' (including root). This then leads to the problem described
above where you cannot (easily) (re)discover what the actual root is.

My proposal differs in that we retain a clear difference between
resource domain / root and threaded (sub)trees.

> > Your objections to doing this were representing the resource controllers
> > in the intermediate thread-only groups like:
> > 
> >    R
> >     \
> >      T  -- what to do with eg. memcg here?
> >       \
> >        D
> >         \
> > 	     T
> 
> And that's a perfectly valid point and as you pointed out the downside
> of marking each node separately is that the interface would allow
> configurations which aren't supported (at least for now) and that
> there's just more to configure - the user has to set the mode on each
> node after creation which is just the natural cost of being able to
> express more.

I'm not sure my proposal results in _more_ configuration per-se. Yes
there are some differences, but they go both ways, with the threaded tag
its easier to create multiple threaded subgroups, but with the domain
tag its easier to create multiple domain subgroups.

And I think the bias for the domain tag -- easier to create more domains
-- is the right one. The whole threaded thing is fairly special purpose.

In any case; I'm fine with initially not supporting domains nested under
thread groups -- although I do think there's valid use-cases for doing
so.

> > I suggested having all resource controllers represented with a soft-link
> > back into the (thread-root) resource domain. But you were not convinced
> > and worried people were going to be confused.
> 
> There's more to it than just confusion because resource interface
> files belong to the parent cgroup rather than the cgroup which hosts
> the files.  This becomes clear when thinking about which files a
> container should be granted write access to when delegating a cgroup
> subtree to it.  I'm sure we can get around it some way but we need to
> be careful here.

I would suggest having all the back-links be RO. That way you can never
grant write permission, can never actually change things that don't make
'sense', but get a really good clue where you need to go.

> > By having both in nice units, its both conceptually clear that they're
> > the same kind of weight and easier to match weights.

> But, it doesn't have to be this or that.  We can easily support both
> units by simply allowing, say, "-5n" to be written to cpu.weight file
> and interpret that as the nice value and exposing the closest nice
> value in the cpu.stat file.
> 
> Does that sound workable?

Not sure; reading the value would become somewhat awkward I suppose. But
maybe we can simply do two files, whichever is written to last takes
precedence. And when a !nice weight is written, the nice file returns
-EINVAL or something.

Not particularly pretty though...

[toc] | [next] | [standalone]

#1684642

On 07/10/2017 04:32 AM, Peter Zijlstra wrote:
> On Fri, Jun 30, 2017 at 09:23:24AM -0400, Tejun Heo wrote:
>> On Tue, Jun 27, 2017 at 09:01:43AM +0200, Peter Zijlstra wrote:
>>> On Mon, Jun 12, 2017 at 05:27:53PM -0400, Tejun Heo wrote:
>>> IIRC the problem with the 'threaded' marker is that it doesn't clearly
>>> capture what a resource domain is.
>>>
>>> That is, assuming that a thread root is always a resource domain, we get
>>> the following problem:
>>>
>>> If we set 'threaded' on the root group in order to create a thread
>>> (sub)group. If we then want to create another domain group, we'd have to
>>> clear 'threaded' on that.
>>>
>>> 	R (t=1)
>>>        / \
>>> (t=1) T   D (t=0)
>>>
>>> So far so good. However, now we want to create another thread group
>>> under our domain group D, so we have to set its 'threaded' marker again:
>>>
>>> 	R (t=1)
>>>        / \
>>> (t=1) T   D (t=1)
>>>          /
>>> 	T (t=1)

This configuration is actually not possible with Tejun's latest v3 patch
which took out the "join" operation. Maybe we should keep the "join"
operation if this configuration is likely to happen.

>>> And we can no longer identify D as a resource domain. If OTOH we mark
>>> 'domain' we get:
>>>
>>> 	R (d=1)
>>>        / \
>>> (d=0) T   D (d=1)
>>>          /
>>> 	T (d=0)
>>>
>>> Which clearly identifies the domains and the thread only groups.
>> So, the difference between the two interfaces is that the one I
>> proposed is marking the thread root which makes all its descendants
>> threaded while the above is marking each individual cgroup as being
>> whether a resource domain or threaded.
> You start by marking the thread root, but then continue to mark all
> 'threaded' (including root). This then leads to the problem described
> above where you cannot (easily) (re)discover what the actual root is.

I don't think that is true. Internally, we can always find out if a
cgroup is a thread root. Externally, the presence of resource domain
control knobs in a threaded cgroup will indicate that it is a thread root.

> My proposal differs in that we retain a clear difference between
> resource domain / root and threaded (sub)trees.

For me, I have no preference of using either the threaded or the domain
marker as long as some kind of join operation that allows the
configuration above is present in the thread mode. They both looks good
to me. It is just a matter of which aspect of the cgroup we want to
emphasize. I would suggest we reach a consensus ASAP and move forward to
other more substantial issues in cgroup v2.

Cheers,
Longman

[toc] | [prev] | [next] | [standalone]

#1684997

On Mon, Jul 10, 2017 at 05:01:19PM -0400, Waiman Long wrote:
> On 07/10/2017 04:32 AM, Peter Zijlstra wrote:
> > On Fri, Jun 30, 2017 at 09:23:24AM -0400, Tejun Heo wrote:
> >> On Tue, Jun 27, 2017 at 09:01:43AM +0200, Peter Zijlstra wrote:
> >>> On Mon, Jun 12, 2017 at 05:27:53PM -0400, Tejun Heo wrote:
> >>> IIRC the problem with the 'threaded' marker is that it doesn't clearly
> >>> capture what a resource domain is.
> >>>
> >>> That is, assuming that a thread root is always a resource domain, we get
> >>> the following problem:
> >>>
> >>> If we set 'threaded' on the root group in order to create a thread
> >>> (sub)group. If we then want to create another domain group, we'd have to
> >>> clear 'threaded' on that.
> >>>
> >>> 	R (t=1)
> >>>        / \
> >>> (t=1) T   D (t=0)
> >>>
> >>> So far so good. However, now we want to create another thread group
> >>> under our domain group D, so we have to set its 'threaded' marker again:
> >>>
> >>> 	R (t=1)
> >>>        / \
> >>> (t=1) T   D (t=1)
> >>>          /
> >>> 	T (t=1)
> 
> This configuration is actually not possible with Tejun's latest v3 patch
> which took out the "join" operation. Maybe we should keep the "join"
> operation if this configuration is likely to happen.

Wait what? Why not? That's a fairly fundamental setup that needs to be
possible. I understood the 'join' thing was for something else entirely.
TJ said the 'join' was to allow thread-roots that were not domain
controllers -- which I didn't get the point of.

> >>> And we can no longer identify D as a resource domain. If OTOH we mark
> >>> 'domain' we get:
> >>>
> >>> 	R (d=1)
> >>>        / \
> >>> (d=0) T   D (d=1)
> >>>          /
> >>> 	T (d=0)
> >>>
> >>> Which clearly identifies the domains and the thread only groups.
> >> So, the difference between the two interfaces is that the one I
> >> proposed is marking the thread root which makes all its descendants
> >> threaded while the above is marking each individual cgroup as being
> >> whether a resource domain or threaded.
> > You start by marking the thread root, but then continue to mark all
> > 'threaded' (including root). This then leads to the problem described
> > above where you cannot (easily) (re)discover what the actual root is.
> 
> I don't think that is true. Internally, we can always find out if a
> cgroup is a thread root. Externally, the presence of resource domain
> control knobs in a threaded cgroup will indicate that it is a thread root.

You're confusing thread root with resource domain. While a resource
domain must be a thread root the reverse is not necessarily so (this is
what I understood the 'join' thing to be for).

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.

> > My proposal differs in that we retain a clear difference between
> > resource domain / root and threaded (sub)trees.
> 
> For me, I have no preference of using either the threaded or the domain
> marker as long as some kind of join operation that allows the
> configuration above is present in the thread mode. They both looks good
> to me. It is just a matter of which aspect of the cgroup we want to
> emphasize. I would suggest we reach a consensus ASAP and move forward to
> other more substantial issues in cgroup v2.

I think you're confused on join. Join should not be needed.

[toc] | [prev] | [next] | [standalone]

#1685058

On 07/11/2017 08:15 AM, Peter Zijlstra wrote:
> On Mon, Jul 10, 2017 at 05:01:19PM -0400, Waiman Long wrote:
>> On 07/10/2017 04:32 AM, Peter Zijlstra wrote:
>>> On Fri, Jun 30, 2017 at 09:23:24AM -0400, Tejun Heo wrote:
>>>> On Tue, Jun 27, 2017 at 09:01:43AM +0200, Peter Zijlstra wrote:
>>>>> On Mon, Jun 12, 2017 at 05:27:53PM -0400, Tejun Heo wrote:
>>>>> IIRC the problem with the 'threaded' marker is that it doesn't clearly
>>>>> capture what a resource domain is.
>>>>>
>>>>> That is, assuming that a thread root is always a resource domain, we get
>>>>> the following problem:
>>>>>
>>>>> If we set 'threaded' on the root group in order to create a thread
>>>>> (sub)group. If we then want to create another domain group, we'd have to
>>>>> clear 'threaded' on that.
>>>>>
>>>>> 	R (t=1)
>>>>>        / \
>>>>> (t=1) T   D (t=0)
>>>>>
>>>>> So far so good. However, now we want to create another thread group
>>>>> under our domain group D, so we have to set its 'threaded' marker again:
>>>>>
>>>>> 	R (t=1)
>>>>>        / \
>>>>> (t=1) T   D (t=1)
>>>>>          /
>>>>> 	T (t=1)
>> This configuration is actually not possible with Tejun's latest v3 patch
>> which took out the "join" operation. Maybe we should keep the "join"
>> operation if this configuration is likely to happen.
> Wait what? Why not? That's a fairly fundamental setup that needs to be
> possible. I understood the 'join' thing was for something else entirely.
> TJ said the 'join' was to allow thread-roots that were not domain
> controllers -- which I didn't get the point of.

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)
       
Instead, you can have

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

With Tejun's v3 patch, the "join" operation was removed and "enable"
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.

>>>>> And we can no longer identify D as a resource domain. If OTOH we mark
>>>>> 'domain' we get:
>>>>>
>>>>> 	R (d=1)
>>>>>        / \
>>>>> (d=0) T   D (d=1)
>>>>>          /
>>>>> 	T (d=0)
>>>>>
>>>>> Which clearly identifies the domains and the thread only groups.
>>>> So, the difference between the two interfaces is that the one I
>>>> proposed is marking the thread root which makes all its descendants
>>>> threaded while the above is marking each individual cgroup as being
>>>> whether a resource domain or threaded.
>>> You start by marking the thread root, but then continue to mark all
>>> 'threaded' (including root). This then leads to the problem described
>>> above where you cannot (easily) (re)discover what the actual root is.
>> I don't think that is true. Internally, we can always find out if a
>> cgroup is a thread root. Externally, the presence of resource domain
>> control knobs in a threaded cgroup will indicate that it is a thread root.
> You're confusing thread root with resource domain. While a resource
> domain must be a thread root the reverse is not necessarily so (this is
> what I understood the 'join' thing to be for).

I know the difference between thread root and resource domain. In the
current scheme, all the cgroups which are not threaded under a thread
root are resource domain.

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

>>> My proposal differs in that we retain a clear difference between
>>> resource domain / root and threaded (sub)trees.
>> For me, I have no preference of using either the threaded or the domain
>> marker as long as some kind of join operation that allows the
>> configuration above is present in the thread mode. They both looks good
>> to me. It is just a matter of which aspect of the cgroup we want to
>> emphasize. I would suggest we reach a consensus ASAP and move forward to
>> other more substantial issues in cgroup v2.
> I think you're confused on join. Join should not be needed.

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

Yes, the "join" operation may not be needed. It is just a matter of how
much flexibility we want to specify the desirable cgroup configuration.

Cheers,
Longman

[toc] | [prev] | [next] | [standalone]

#1685208

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.

[toc] | [prev] | [next] | [standalone]

#1685347

On 07/11/2017 12:52 PM, Peter Zijlstra wrote:
> 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)

Tejun's thread mode patch has constraints on what operations are allowed
and what aren't. For a threaded subtree, thread mode cannot be disabled
in the middle of the tree. You have to remove all the child cgroups in
the subtree before you can disable thread mode at the thread root level.
So the second step will not be allowed. We can certainly argue if it is
a good thing or not. What I am talking about is the current behavior of
the patch.

>> With Tejun's v3 patch, the "join" operation was removed and "enable"
> I've no clue what 'enable' is... :-(

The keywords to turn on and off thread mode are:

enable: t=1
disable: t=0

As discussed above, there are constraints on when that transition is
allowed to happen.

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

The constraints are there to make it easier to code and observe
guidelines like no internal process constraint. So what you said above
is not current allowed.

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

For thread mode, the only way to find out if a cgroup is in that mode is
to dump out the content of the cgroup.procs and cgroup.threads files.
Reading cgroup.threads will return error if thread mode is not enabled.
Reading cgroup.procs is allowed in the thread root, but not in the rest
of the threaded subtree. So there is a way to find out, but kind of
indirect.


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

OK.

>> 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.
>
Agreed.

Cheers,
Longman

[toc] | [prev] | [next] | [standalone]

#1685578

On Tue, Jul 11, 2017 at 05:12:39PM -0400, Waiman Long wrote:
> On 07/11/2017 12:52 PM, Peter Zijlstra wrote:
> > 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)
> 
> Tejun's thread mode patch has constraints on what operations are allowed
> and what aren't. For a threaded subtree, thread mode cannot be disabled
> in the middle of the tree.

Where in that scenario did I change anything in the middle? All
operations were on a leaf group.

[toc] | [prev] | [next] | [standalone]

#1685798

On 07/12/2017 03:45 AM, Peter Zijlstra wrote:
> On Tue, Jul 11, 2017 at 05:12:39PM -0400, Waiman Long wrote:
>> On 07/11/2017 12:52 PM, Peter Zijlstra wrote:
>>> 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)
>> Tejun's thread mode patch has constraints on what operations are allowed
>> and what aren't. For a threaded subtree, thread mode cannot be disabled
>> in the middle of the tree.
> Where in that scenario did I change anything in the middle? All
> operations were on a leaf group.

What I mean is that you can't disable thread mode if not at the thread
root with no children left.

Cheers,
Longman

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web