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

Groups > linux.kernel > #1672020 > unrolled thread

Re: [RFC PATCH-cgroup 1/6] cgroup: Relax the no internal process constraint

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: [RFC PATCH-cgroup 1/6] cgroup: Relax the no internal process  constraint Tejun Heo <tj@kernel.org> - 2017-06-21 22:50 +0200
    Re: [RFC PATCH-cgroup 1/6] cgroup: Relax the no internal process  constraint Tejun Heo <tj@kernel.org> - 2017-06-21 23:40 +0200
      Re: [RFC PATCH-cgroup 1/6] cgroup: Relax the no internal process  constraint Waiman Long <longman@redhat.com> - 2017-06-22 00:00 +0200
        Re: [RFC PATCH-cgroup 1/6] cgroup: Relax the no internal process  constraint Tejun Heo <tj@kernel.org> - 2017-06-22 00:10 +0200
    Re: [RFC PATCH-cgroup 1/6] cgroup: Relax the no internal process  constraint Waiman Long <longman@redhat.com> - 2017-06-21 23:40 +0200

#1672020 — Re: [RFC PATCH-cgroup 1/6] cgroup: Relax the no internal process constraint

Hello, Waiman.

On Wed, Jun 14, 2017 at 11:05:32AM -0400, Waiman Long wrote:
>  2-4-3. No Internal Process Constraint
>  
> +When a non-root cgroup distributes resources to their children while
> +having processes of its own, its internal processes will then compete
> +against its children in term of resource allocation.  For some resource
> +types, that is not a problem and the controllers are able to handle
> +them correctly.  For others, the controllers may not be able to handle
> +internal process competition correctly.  This type of controllers are
> +called resource domain controllers in this document.
> +
> +Internal processes are not allowed on non-root cgroups which has
> +any one of those resource domain controllers enabled.  Currently all
> +controllers that are allowed in a threaded cgroup will be considered
> +as a non-resource domain controller and hence will not block internal
> +processes.  In other words, only cgroups which don't contain any

This isn't on this patch but I'm not sure this is a good way to define
resource domain controllers.  We probably should first define resource
domains and walk our way in to the accompanying restrictions and then
the distinction between the controller types.

...
> +Note that the restriction doesn't get in the way if there is no resource
> +domain controller enabled in the cgroup's "cgroup.subtree_control".
> +This is important as otherwise it wouldn't be possible to create
> +children of a populated cgroup.  To control resource distribution
> +of a cgroup, the cgroup must create children and transfer all
> +its processes to the children before enabling controllers in its
> +"cgroup.subtree_control" file.

What happens when we add domain handling to CPU so that it is both a
domain and resource controller?  Even if that somehow can be resolved,
wouldn't that come with a rather surprising userland behavior changes?
Also, I'm not sure what we're achieving by doing this.  It doesn't
really relax the restriction.  It just turns it off implicitly when
certain conditions are met, which doesn't really allow any real
capabilities and at least to me the behaviors feel more subtle and
complicated than before.

Thanks.

-- 
tejun

[toc] | [next] | [standalone]

#1672073

Hello,

On Wed, Jun 21, 2017 at 05:37:00PM -0400, Waiman Long wrote:
> > What happens when we add domain handling to CPU so that it is both a
> > domain and resource controller?  Even if that somehow can be resolved,
> > wouldn't that come with a rather surprising userland behavior changes?
> > Also, I'm not sure what we're achieving by doing this.  It doesn't
> > really relax the restriction.  It just turns it off implicitly when
> > certain conditions are met, which doesn't really allow any real
> > capabilities and at least to me the behaviors feel more subtle and
> > complicated than before.
> 
> I think CPU isn't a good example for that.

Can you please elaborate?

> Another alternative is to treat no internal process as a controller
> attribute. Then we don't need to worry about this intricate question and
> let the  controllers decide if they will allow internal processes.

Isn't that what "threaded" is?

Thanks.

-- 
tejun

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

#1672091

On 06/21/2017 05:39 PM, Tejun Heo wrote:
> Hello,
>
> On Wed, Jun 21, 2017 at 05:37:00PM -0400, Waiman Long wrote:
>>> What happens when we add domain handling to CPU so that it is both a
>>> domain and resource controller?  Even if that somehow can be resolved,
>>> wouldn't that come with a rather surprising userland behavior changes?
>>> Also, I'm not sure what we're achieving by doing this.  It doesn't
>>> really relax the restriction.  It just turns it off implicitly when
>>> certain conditions are met, which doesn't really allow any real
>>> capabilities and at least to me the behaviors feel more subtle and
>>> complicated than before.
>> I think CPU isn't a good example for that.
> Can you please elaborate?

CPU is probably the most prominent controller where deep hierarchy has a
performance cost. So I can't envision that it will forbid internal
process competition.
 
>> Another alternative is to treat no internal process as a controller
>> attribute. Then we don't need to worry about this intricate question and
>> let the  controllers decide if they will allow internal processes.
> Isn't that what "threaded" is?
>

That is exactly what this patch intends to do. However, you raised
concern that threaded may not be equivalent to the need of allowing
internal process. That is why I propose that. If your concern is only
about the documentation change, we can certainly fix that.

Cheers,
Longman

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

#1672107

Hey,

On Wed, Jun 21, 2017 at 05:50:09PM -0400, Waiman Long wrote:
> >> I think CPU isn't a good example for that.
> > Can you please elaborate?
> 
> CPU is probably the most prominent controller where deep hierarchy has a
> performance cost. So I can't envision that it will forbid internal
> process competition.

I think there's a fundamental misunderstanding here.  The internal
competion thing is about how to account for resource consumptions
which aren't tied to specific processes or tasks.  Thread mode allows
building sub-hierarchy beyond the domain point while still keeping the
domain at the root of the thread subtree.  It is true that as
currently implemented, CPU controller has performance issues for some
workloads even with a moderate level of nesting (and quite a bit of
other artifacts from nesting too); however, supporting control of
anonymous resources or not is an orthogonal issue.  People can enable
thread mode at the root if that's applicable to the workload at hand
but you can't change what the basic topology means because a
controller has performance overhead.

> >> Another alternative is to treat no internal process as a controller
> >> attribute. Then we don't need to worry about this intricate question and
> >> let the  controllers decide if they will allow internal processes.
> > Isn't that what "threaded" is?
> 
> That is exactly what this patch intends to do. However, you raised
> concern that threaded may not be equivalent to the need of allowing
> internal process. That is why I propose that. If your concern is only
> about the documentation change, we can certainly fix that.

I'm really lost on what this actually achieves.  Can we please first
talk about what you're trying to enable?  Let's talk about features
and capabilities first because it feels like most of the changes in
this patchset lack them and we seem to be talking past each other.

Thanks.

-- 
tejun

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

#1672076

On 06/21/2017 04:40 PM, Tejun Heo wrote:
> Hello, Waiman.
>
> On Wed, Jun 14, 2017 at 11:05:32AM -0400, Waiman Long wrote:
>>  2-4-3. No Internal Process Constraint
>>  
>> +When a non-root cgroup distributes resources to their children while
>> +having processes of its own, its internal processes will then compete
>> +against its children in term of resource allocation.  For some resource
>> +types, that is not a problem and the controllers are able to handle
>> +them correctly.  For others, the controllers may not be able to handle
>> +internal process competition correctly.  This type of controllers are
>> +called resource domain controllers in this document.
>> +
>> +Internal processes are not allowed on non-root cgroups which has
>> +any one of those resource domain controllers enabled.  Currently all
>> +controllers that are allowed in a threaded cgroup will be considered
>> +as a non-resource domain controller and hence will not block internal
>> +processes.  In other words, only cgroups which don't contain any
> This isn't on this patch but I'm not sure this is a good way to define
> resource domain controllers.  We probably should first define resource
> domains and walk our way in to the accompanying restrictions and then
> the distinction between the controller types.

This patch essentially allows internal process when non of the resource
domain controllers are enabled in the sense that they are activated by
the subtree_control file of the parent. I do agree that we should
probably define resource domain as a separate topic in this document. It
is true that a resource domain controller is not technically equivalent
to the !threaded controller, but this is the best that we have unless we
introduce another controller attribute for resource domain. I have tried
to do that in some of my past patches. I think PeterZ had suggested too.

The main purpose to not make thread mode special for internal process
handling. Instead, internal processes are allowed because no resource
domain controllers are enabled whether or not thread mode is enabled or
not. I think that is more consistent than treating thread mode as special.

> ...
>> +Note that the restriction doesn't get in the way if there is no resource
>> +domain controller enabled in the cgroup's "cgroup.subtree_control".
>> +This is important as otherwise it wouldn't be possible to create
>> +children of a populated cgroup.  To control resource distribution
>> +of a cgroup, the cgroup must create children and transfer all
>> +its processes to the children before enabling controllers in its
>> +"cgroup.subtree_control" file.
> What happens when we add domain handling to CPU so that it is both a
> domain and resource controller?  Even if that somehow can be resolved,
> wouldn't that come with a rather surprising userland behavior changes?
> Also, I'm not sure what we're achieving by doing this.  It doesn't
> really relax the restriction.  It just turns it off implicitly when
> certain conditions are met, which doesn't really allow any real
> capabilities and at least to me the behaviors feel more subtle and
> complicated than before.
>
> Thanks.

I think CPU isn't a good example for that.

Another alternative is to treat no internal process as a controller
attribute. Then we don't need to worry about this intricate question and
let the  controllers decide if they will allow internal processes.

Cheers,
Longman

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web