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

Groups > linux.kernel > #1688595 > unrolled thread

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

Back to article view | Back to linux.kernel

Contents

  [PATCHSET for-4.13] cgroup: implement cgroup2 thread mode, v3 Tejun Heo <tj@kernel.org> - 2017-07-17 04:10 +0200
    [PATCH 2/6] cgroup: add @flags to css_task_iter_start() and implement CSS_TASK_ITER_PROCS Tejun Heo <tj@kernel.org> - 2017-07-17 04:10 +0200
    [PATCH 1/6] cgroup: reorganize cgroup.procs / task write path Tejun Heo <tj@kernel.org> - 2017-07-17 04:10 +0200
    [PATCH 3/6] cgroup: introduce cgroup->dom_cgrp and threaded css_set handling Tejun Heo <tj@kernel.org> - 2017-07-17 04:10 +0200
    [PATCH 6/6] cgroup: update debug controller to print out thread mode information Tejun Heo <tj@kernel.org> - 2017-07-17 04:10 +0200
      Re: [PATCH 6/6] cgroup: update debug controller to print out thread  mode information Waiman Long <longman@redhat.com> - 2017-07-17 23:20 +0200
        Re: [PATCH 6/6] cgroup: update debug controller to print out thread  mode information Tejun Heo <tj@kernel.org> - 2017-07-19 17:40 +0200
          Re: [PATCH 6/6] cgroup: update debug controller to print out thread  mode information Waiman Long <longman@redhat.com> - 2017-07-19 17:50 +0200
            Re: [PATCH 6/6] cgroup: update debug controller to print out thread  mode information Tejun Heo <tj@kernel.org> - 2017-07-19 17:50 +0200
    [PATCH 5/6] cgroup: implement cgroup v2 thread support Tejun Heo <tj@kernel.org> - 2017-07-17 04:10 +0200
      Re: [PATCH 5/6] cgroup: implement cgroup v2 thread support Peter Zijlstra <peterz@infradead.org> - 2017-07-17 16:20 +0200
        Re: [PATCH 5/6] cgroup: implement cgroup v2 thread support Tejun Heo <tj@kernel.org> - 2017-07-17 16:30 +0200
          Re: [PATCH 5/6] cgroup: implement cgroup v2 thread support Peter Zijlstra <peterz@infradead.org> - 2017-07-18 19:30 +0200
            Re: [PATCH 5/6] cgroup: implement cgroup v2 thread support Waiman Long <longman@redhat.com> - 2017-07-18 19:40 +0200
            Re: [PATCH 5/6] cgroup: implement cgroup v2 thread support Tejun Heo <tj@kernel.org> - 2017-07-18 20:00 +0200
              Re: [PATCH 5/6] cgroup: implement cgroup v2 thread support Peter Zijlstra <peterz@infradead.org> - 2017-07-18 20:50 +0200
                Re: [PATCH 5/6] cgroup: implement cgroup v2 thread support Tejun Heo <tj@kernel.org> - 2017-07-18 20:50 +0200
                  Re: [PATCH 5/6] cgroup: implement cgroup v2 thread support Peter Zijlstra <peterz@infradead.org> - 2017-07-19 16:10 +0200
                    Re: [PATCH 5/6] cgroup: implement cgroup v2 thread support Tejun Heo <tj@kernel.org> - 2017-07-19 18:40 +0200
        Re: [PATCH 5/6] cgroup: implement cgroup v2 thread support Waiman Long <longman@redhat.com> - 2017-07-17 23:00 +0200
          Re: [PATCH 5/6] cgroup: implement cgroup v2 thread support Waiman Long <longman@redhat.com> - 2017-07-18 16:40 +0200
            Re: [PATCH 5/6] cgroup: implement cgroup v2 thread support Tejun Heo <tj@kernel.org> - 2017-07-18 19:20 +0200
              Re: [PATCH 5/6] cgroup: implement cgroup v2 thread support Waiman Long <longman@redhat.com> - 2017-07-18 19:30 +0200
                Re: [PATCH 5/6] cgroup: implement cgroup v2 thread support Tejun Heo <tj@kernel.org> - 2017-07-19 18:30 +0200
                  Re: [PATCH 5/6] cgroup: implement cgroup v2 thread support Waiman Long <longman@redhat.com> - 2017-07-19 19:10 +0200
                    Re: [PATCH 5/6] cgroup: implement cgroup v2 thread support Tejun Heo <tj@kernel.org> - 2017-07-19 19:50 +0200
      Re: [PATCH 5/6] cgroup: implement cgroup v2 thread support Waiman Long <longman@redhat.com> - 2017-07-17 23:20 +0200
        Re: [PATCH 5/6] cgroup: implement cgroup v2 thread support Tejun Heo <tj@kernel.org> - 2017-07-19 17:50 +0200
    [PATCH 4/6] cgroup: implement CSS_TASK_ITER_THREADED Tejun Heo <tj@kernel.org> - 2017-07-17 04:10 +0200
    Re: [PATCHSET for-4.13] cgroup: implement cgroup2 thread mode, v3 Waiman Long <longman@redhat.com> - 2017-07-17 16:50 +0200
      Re: [PATCHSET for-4.13] cgroup: implement cgroup2 thread mode, v3 Tejun Heo <tj@kernel.org> - 2017-07-17 17:00 +0200

Page 2 of 2 — ← Prev page 1 [2]

#1690328 — Re: [PATCH 5/6] cgroup: implement cgroup v2 thread support

On 07/17/2017 04:56 PM, Waiman Long wrote:
> On 07/17/2017 10:14 AM, Peter Zijlstra wrote:
>> On Sun, Jul 16, 2017 at 10:07:20PM -0400, Tejun Heo wrote:
>>> v4: - Updated to marking each cgroup threaded as suggested by PeterZ.
>>>
>>> +On creation, a cgroup is always a domain cgroup and can be made
>>> +threaded by writing "threaded" to the "cgroup.type" file.  The
>>> +operation is single direction::
>>> +
>>> +  # echo threaded > cgroup.type
>>> +
>>> +Once threaded, the cgroup can't be made a domain again.  To enable the
>>> +thread mode, the following conditions must be met.
>>> +
>>> +- As the cgroup will join the parent's resource domain.  The parent
>>> +  must either be a valid (threaded) domain or a threaded cgroup.
>>> +
>>> +- The cgroup must be empty.  No enabled controllers, child cgroups or
>>> +  processes.
>>> +
>>> +Topology-wise, a cgroup can be in an invalid state.  Please consider
>>> +the following toplogy::
>>> +
>>> +  A (threaded domain) - B (threaded) - C (domain, just created)
>>> +

Thinking about it some more. There is a place for invalid domain. It is
not the child of a threaded cgroup. It is the siblings of a threaded
cgroup whose parent is not root.

       Root - A (domain) - B (domain)
                         \ C (domain)

With "echo threaded > B/cgroup.type":

       Root - A (threaded domain) - B (threaded)
                                  \ C (domain, invalid)

Any children of a threaded cgroup should be threaded.

Cheers,
Longman

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

#1690499 — Re: [PATCH 5/6] cgroup: implement cgroup v2 thread support

Hello, Waiman.

On Tue, Jul 18, 2017 at 10:37:41AM -0400, Waiman Long wrote:
> Thinking about it some more. There is a place for invalid domain. It is
> not the child of a threaded cgroup. It is the siblings of a threaded
> cgroup whose parent is not root.
> 
>        Root - A (domain) - B (domain)
>                          \ C (domain)
> 
> With "echo threaded > B/cgroup.type":
> 
>        Root - A (threaded domain) - B (threaded)
>                                   \ C (domain, invalid)

Yes, I noted that when I was replying to Peter.

> Any children of a threaded cgroup should be threaded.

It's really difficult to discuss if you just declare that something
should be a certain way without giving rationale for thinking so.

If we could get rid of the invalid state completely that way, I'd
completely agree with you but that isn't the case here as you noted
yourself, so the choice between the two isn't something trivially
clear.  Both choices come with their pros and cons.  We can absoultely
discuss them comparing the pros and cons.

Thanks.

-- 
tejun

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

#1690513 — Re: [PATCH 5/6] cgroup: implement cgroup v2 thread support

On 07/18/2017 01:10 PM, Tejun Heo wrote:
> Hello, Waiman.
>
> On Tue, Jul 18, 2017 at 10:37:41AM -0400, Waiman Long wrote:
>> Thinking about it some more. There is a place for invalid domain. It is
>> not the child of a threaded cgroup. It is the siblings of a threaded
>> cgroup whose parent is not root.
>>
>>        Root - A (domain) - B (domain)
>>                          \ C (domain)
>>
>> With "echo threaded > B/cgroup.type":
>>
>>        Root - A (threaded domain) - B (threaded)
>>                                   \ C (domain, invalid)
> Yes, I noted that when I was replying to Peter.
>
>> Any children of a threaded cgroup should be threaded.
> It's really difficult to discuss if you just declare that something
> should be a certain way without giving rationale for thinking so.
>
> If we could get rid of the invalid state completely that way, I'd
> completely agree with you but that isn't the case here as you noted
> yourself, so the choice between the two isn't something trivially
> clear.  Both choices come with their pros and cons.  We can absoultely
> discuss them comparing the pros and cons.
I am not advocating on removing the invalid state now as I note about
sibling cgroups. I am just saying that there is no point in not doing an
automatic conversion to threaded for newly created children of threaded
cgroups (not thread root). I don't see any cons in doing that.

Cheers,
Longman

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

#1692012 — Re: [PATCH 5/6] cgroup: implement cgroup v2 thread support

Hello,

On Tue, Jul 18, 2017 at 01:23:14PM -0400, Waiman Long wrote:
> > If we could get rid of the invalid state completely that way, I'd
> > completely agree with you but that isn't the case here as you noted
> > yourself, so the choice between the two isn't something trivially
> > clear.  Both choices come with their pros and cons.  We can absoultely
> > discuss them comparing the pros and cons.
>
> I am not advocating on removing the invalid state now as I note about

Yeah, removing invalid state would be great but we can't at least yet.

> sibling cgroups. I am just saying that there is no point in not doing an
> automatic conversion to threaded for newly created children of threaded
> cgroups (not thread root). I don't see any cons in doing that.

So, the cons I see is inconsistency, now and in the future.

This may seem less clear with system root because we can have both
domain and theraded children below it, which makes a newly created
cgroup being a domain seem natural.  More importantly, we can't do it
any other way because we'd break existing users otherwise - creating a
threaded cgroup would cause future first level cgroups to be threaded
which will be very unexpected.

Let's think about a non-root threaded domain.  At least for now, a
non-root threaded domain is terminal - they can't host valid domain
children.  As the alternative term "thread root" implies, the threaded
domain can be the root of a threaded subtree and nothing else, so it's
kinda weird to make a new child cgroup there start out as a domain
which can't be used, just like it'd be for the second level descendant
cgroup.

However, the alternative is even stranger.  Let's say we make the
first level child automatically threaded, but that is inconsistent
with when we first enable threaded mode.  We either would have to turn
all siblings at the same time or disallow enabling threaded mode if
there are domain siblings, which I fear would be unnecessarily
restrictive.

Another point is that what if we eventually make non-root threaded
roots able to host domain children?  Making children automatically
threaded wouldn't make any sense then, right?  I'll come back to this
later.

So, it looks like if we're gonna automatically turn on threaded mode
for new cgroups, the only thing we can do right now is what you're
suggesting; however, we didn't arrive there through some
straight-forward intuition or overall design.  It started as a simple
idea (I want it to be automatic) but the end result is a contorted
destination shaped by constraints and happenstance.

To me, behaving differently on the first-level threaded children than
on second+ level ones is too strange to be justified by the
convenience of not having to turn on threaded on new cgroups.

On top of that, what happens if we get to implement PeterZ's idea of
skipping over threaded internal cgroups to allow domains under
threaded subtrees?  That'd imply that we'd be able to host domains
under threaded domains too.  The end result would be completely
non-sensical.  We'd be defaulting to different modes for different
reasons where half of those reasons won't hold anymore.  This isn't
surprising given that there's nothing actually consistent about the
suggested default behavior.

So, that's why I think it'd be better to be simple here, even if that
adds a bit of hassle when creating threded children.  It is simple and
consistent and can stay that way even if we make the hierarchy more
flexible in the future.

Thanks.

-- 
tejun

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

#1692038 — Re: [PATCH 5/6] cgroup: implement cgroup v2 thread support

On 07/19/2017 12:29 PM, Tejun Heo wrote:
> Hello,
>
> On Tue, Jul 18, 2017 at 01:23:14PM -0400, Waiman Long wrote:
>>> If we could get rid of the invalid state completely that way, I'd
>>> completely agree with you but that isn't the case here as you noted
>>> yourself, so the choice between the two isn't something trivially
>>> clear.  Both choices come with their pros and cons.  We can absoultely
>>> discuss them comparing the pros and cons.
>> I am not advocating on removing the invalid state now as I note about
> Yeah, removing invalid state would be great but we can't at least yet.
>
>> sibling cgroups. I am just saying that there is no point in not doing an
>> automatic conversion to threaded for newly created children of threaded
>> cgroups (not thread root). I don't see any cons in doing that.
> So, the cons I see is inconsistency, now and in the future.
>
> This may seem less clear with system root because we can have both
> domain and theraded children below it, which makes a newly created
> cgroup being a domain seem natural.  More importantly, we can't do it
> any other way because we'd break existing users otherwise - creating a
> threaded cgroup would cause future first level cgroups to be threaded
> which will be very unexpected.
>
> Let's think about a non-root threaded domain.  At least for now, a
> non-root threaded domain is terminal - they can't host valid domain
> children.  As the alternative term "thread root" implies, the threaded
> domain can be the root of a threaded subtree and nothing else, so it's
> kinda weird to make a new child cgroup there start out as a domain
> which can't be used, just like it'd be for the second level descendant
> cgroup.
>
> However, the alternative is even stranger.  Let's say we make the
> first level child automatically threaded, but that is inconsistent
> with when we first enable threaded mode.  We either would have to turn
> all siblings at the same time or disallow enabling threaded mode if
> there are domain siblings, which I fear would be unnecessarily
> restrictive.
>
> Another point is that what if we eventually make non-root threaded
> roots able to host domain children?  Making children automatically
> threaded wouldn't make any sense then, right?  I'll come back to this
> later.
>
> So, it looks like if we're gonna automatically turn on threaded mode
> for new cgroups, the only thing we can do right now is what you're
> suggesting; however, we didn't arrive there through some
> straight-forward intuition or overall design.  It started as a simple
> idea (I want it to be automatic) but the end result is a contorted
> destination shaped by constraints and happenstance.
>
> To me, behaving differently on the first-level threaded children than
> on second+ level ones is too strange to be justified by the
> convenience of not having to turn on threaded on new cgroups.

OK, I get your point of being inconsistent. However, I don't think that
is a big deal.

> On top of that, what happens if we get to implement PeterZ's idea of
> skipping over threaded internal cgroups to allow domains under
> threaded subtrees?  That'd imply that we'd be able to host domains
> under threaded domains too.  The end result would be completely
> non-sensical.  We'd be defaulting to different modes for different
> reasons where half of those reasons won't hold anymore.  This isn't
> surprising given that there's nothing actually consistent about the
> suggested default behavior.

For me, that is the only good reason why we should keep the current
behavior. So I am fine with that.

+ cgrp->dom_cgrp = cgrp->dom_cgrp;

However, I am still puzzled by above line of code, should it be just

  cgrp->dom_cgrp = cgrp;

Cheers,
Longman

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

#1692063 — Re: [PATCH 5/6] cgroup: implement cgroup v2 thread support

Hello, Waiman.

On Wed, Jul 19, 2017 at 01:09:38PM -0400, Waiman Long wrote:
> For me, that is the only good reason why we should keep the current
> behavior. So I am fine with that.
> 
> + cgrp->dom_cgrp = cgrp->dom_cgrp;
> 
> However, I am still puzzled by above line of code, should it be just
> 
>   cgrp->dom_cgrp = cgrp;

Oh I see.  Yeah, that's just a silly (harmless) bug.  The field gets
properly initialized in init_cgroup_housekeeping().  I'll remove that
line.

Thanks!

-- 
tejun

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

#1689488 — Re: [PATCH 5/6] cgroup: implement cgroup v2 thread support

On 07/16/2017 10:07 PM, Tejun Heo wrote:
>  
> +Threads
> +~~~~~~~
> +
> +cgroup v2 supports thread granularity for a subset of controllers to
> +support use cases requiring hierarchical resource distribution across
> +the threads of a group of processes.  By default, all threads of a
> +process belong to the same cgroup, which also serves as the resource
> +domain to host resource consumptions which are not specific to a
> +process or thread.  The thread mode allows threads to be spread across
> +a subtree while still maintaining the common resource domain for them.
> +
> +Controllers which support thread mode are called threaded controllers.
> +The ones which don't are called domain controllers.
> +
> +Marking a cgroup threaded makes it join the resource domain of its
> +parent as a threaded cgroup.  The parent may be another threaded
> +cgroup whose resource domain is further up in the hierarchy.  The root
> +of a threaded subtree, that is, the nearest ancestor which is not
> +threaded, is called threaded domain and serves as the resource domain
> +for the entire subtree.

The cgroup code uses the term "thread root" in quite a number of places.
So a developer may be confused when comparing the code and the
documentation. I would recommend either introducing "thread root" as an
alias for threaded domain here in the documentation or documenting that
"threaded domain = thread root" in the code.

> +  cgroup.type
> +
> +	A read-write single value file which exists on non-root
> +	cgroups.
> +
> +	When read, it indicates the current type of the cgroup, which
> +	can be one of the following values.
> +
> +	- "domain" : A normal valid domain cgroup.
> +
> +	- "domain (threaded)" : A threaded domain cgroup which is
> +          serving as the root of a threaded subtree.
> +
> +	- "domain (invalid)" : A cgroup which is in an invalid state.
> +	  It can't be populated or have controllers enabled.  It may
> +	  be allowed to become a threaded cgroup.
> +
> +	- "threaded" : A threaded cgroup which is a member of a
> +          threaded subtree.
> +
> +	A cgroup can be turned into a threaded cgroup by writing
> +	"threaded" to this file.
> +
>    cgroup.procs
>  	A read-write new-line separated values file which exists on
>  	all cgroups.

Do we need to document that cgroup.procs isn't writable in a threaded
cgroup?

> @@ -4301,6 +4606,7 @@ static struct cgroup *cgroup_create(struct cgroup *parent)
>  	cgrp->self.parent = &parent->self;
>  	cgrp->root = root;
>  	cgrp->level = level;
> +	cgrp->dom_cgrp = cgrp->dom_cgrp;

It is a no-op. I think it is better to modify it to

+    cgrp->dom_cgrp = cgroup_is_threaded(parent) ? parent->dom_cgrp : cgrp;

Then we won't have an invalid domain state.

Cheers,
Longman

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

#1691922 — Re: [PATCH 5/6] cgroup: implement cgroup v2 thread support

Hello, Waiman.

On Mon, Jul 17, 2017 at 05:12:31PM -0400, Waiman Long wrote:
> > +Marking a cgroup threaded makes it join the resource domain of its
> > +parent as a threaded cgroup.  The parent may be another threaded
> > +cgroup whose resource domain is further up in the hierarchy.  The root
> > +of a threaded subtree, that is, the nearest ancestor which is not
> > +threaded, is called threaded domain and serves as the resource domain
> > +for the entire subtree.
> 
> The cgroup code uses the term "thread root" in quite a number of places.
> So a developer may be confused when comparing the code and the
> documentation. I would recommend either introducing "thread root" as an
> alias for threaded domain here in the documentation or documenting that
> "threaded domain = thread root" in the code.

Yeah, I was a bit hesitant to introduce an extra term for it, but both
terms make sense and thread root is less cumbersome.  I'll incorporate
it into the doc.

> >    cgroup.procs
> >  	A read-write new-line separated values file which exists on
> >  	all cgroups.
> 
> Do we need to document that cgroup.procs isn't writable in a threaded
> cgroup?

Yeah, will update.

> > @@ -4301,6 +4606,7 @@ static struct cgroup *cgroup_create(struct cgroup *parent)
> >  	cgrp->self.parent = &parent->self;
> >  	cgrp->root = root;
> >  	cgrp->level = level;
> > +	cgrp->dom_cgrp = cgrp->dom_cgrp;
> 
> It is a no-op. I think it is better to modify it to
> 
> +    cgrp->dom_cgrp = cgroup_is_threaded(parent) ? parent->dom_cgrp : cgrp;
> 
> Then we won't have an invalid domain state.

I'll respond to this on the other sub-thread.

Thanks.

-- 
tejun

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

#1688601 — [PATCH 4/6] cgroup: implement CSS_TASK_ITER_THREADED

cgroup v2 is in the process of growing thread granularity support.
Once thread mode is enabled, the root cgroup of the subtree serves as
the dom_cgrp to which the processes of the subtree conceptually belong
and domain-level resource consumptions not tied to any specific task
are charged.  In the subtree, threads won't be subject to process
granularity or no-internal-task constraint and can be distributed
arbitrarily across the subtree.

This patch implements a new task iterator flag CSS_TASK_ITER_THREADED,
which, when used on a dom_cgrp, makes the iteration include the tasks
on all the associated threaded css_sets.  "cgroup.procs" read path is
updated to use it so that reading the file on a proc_cgrp lists all
processes.  This will also be used by controller implementations which
need to walk processes or tasks at the resource domain level.

Task iteration is implemented nested in css_set iteration.  If
CSS_TASK_ITER_THREADED is specified, after walking tasks of each
!threaded css_set, all the associated threaded css_sets are visited
before moving onto the next !threaded css_set.

v2: ->cur_pcset renamed to ->cur_dcset.  Updated for the new
    enable-threaded-per-cgroup behavior.

Signed-off-by: Tejun Heo <tj@kernel.org>
---
 include/linux/cgroup.h |  6 ++++
 kernel/cgroup/cgroup.c | 77 +++++++++++++++++++++++++++++++++++++++-----------
 2 files changed, 66 insertions(+), 17 deletions(-)

diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h
index b7dd230..79faa64 100644
--- a/include/linux/cgroup.h
+++ b/include/linux/cgroup.h
@@ -38,6 +38,8 @@
 
 /* walk only threadgroup leaders */
 #define CSS_TASK_ITER_PROCS		(1U << 0)
+/* walk all threaded css_sets in the domain */
+#define CSS_TASK_ITER_THREADED		(1U << 1)
 
 /* a css_task_iter should be treated as an opaque object */
 struct css_task_iter {
@@ -47,11 +49,15 @@ struct css_task_iter {
 	struct list_head		*cset_pos;
 	struct list_head		*cset_head;
 
+	struct list_head		*tcset_pos;
+	struct list_head		*tcset_head;
+
 	struct list_head		*task_pos;
 	struct list_head		*tasks_head;
 	struct list_head		*mg_tasks_head;
 
 	struct css_set			*cur_cset;
+	struct css_set			*cur_dcset;
 	struct task_struct		*cur_task;
 	struct list_head		iters_node;	/* css_set->task_iters */
 };
diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c
index c7e1c24..a1d59af 100644
--- a/kernel/cgroup/cgroup.c
+++ b/kernel/cgroup/cgroup.c
@@ -3629,6 +3629,58 @@ bool css_has_online_children(struct cgroup_subsys_state *css)
 	return ret;
 }
 
+static struct css_set *css_task_iter_next_css_set(struct css_task_iter *it)
+{
+	struct list_head *l;
+	struct cgrp_cset_link *link;
+	struct css_set *cset;
+
+	lockdep_assert_held(&css_set_lock);
+
+	/* find the next threaded cset */
+	if (it->tcset_pos) {
+		l = it->tcset_pos->next;
+
+		if (l != it->tcset_head) {
+			it->tcset_pos = l;
+			return container_of(l, struct css_set,
+					    threaded_csets_node);
+		}
+
+		it->tcset_pos = NULL;
+	}
+
+	/* find the next cset */
+	l = it->cset_pos;
+	l = l->next;
+	if (l == it->cset_head) {
+		it->cset_pos = NULL;
+		return NULL;
+	}
+
+	if (it->ss) {
+		cset = container_of(l, struct css_set, e_cset_node[it->ss->id]);
+	} else {
+		link = list_entry(l, struct cgrp_cset_link, cset_link);
+		cset = link->cset;
+	}
+
+	it->cset_pos = l;
+
+	/* initialize threaded css_set walking */
+	if (it->flags & CSS_TASK_ITER_THREADED) {
+		if (it->cur_dcset)
+			put_css_set_locked(it->cur_dcset);
+		it->cur_dcset = cset;
+		get_css_set(cset);
+
+		it->tcset_head = &cset->threaded_csets;
+		it->tcset_pos = &cset->threaded_csets;
+	}
+
+	return cset;
+}
+
 /**
  * css_task_iter_advance_css_set - advance a task itererator to the next css_set
  * @it: the iterator to advance
@@ -3637,32 +3689,19 @@ bool css_has_online_children(struct cgroup_subsys_state *css)
  */
 static void css_task_iter_advance_css_set(struct css_task_iter *it)
 {
-	struct list_head *l = it->cset_pos;
-	struct cgrp_cset_link *link;
 	struct css_set *cset;
 
 	lockdep_assert_held(&css_set_lock);
 
 	/* Advance to the next non-empty css_set */
 	do {
-		l = l->next;
-		if (l == it->cset_head) {
-			it->cset_pos = NULL;
+		cset = css_task_iter_next_css_set(it);
+		if (!cset) {
 			it->task_pos = NULL;
 			return;
 		}
-
-		if (it->ss) {
-			cset = container_of(l, struct css_set,
-					    e_cset_node[it->ss->id]);
-		} else {
-			link = list_entry(l, struct cgrp_cset_link, cset_link);
-			cset = link->cset;
-		}
 	} while (!css_set_populated(cset));
 
-	it->cset_pos = l;
-
 	if (!list_empty(&cset->tasks))
 		it->task_pos = cset->tasks.next;
 	else
@@ -3805,6 +3844,9 @@ void css_task_iter_end(struct css_task_iter *it)
 		spin_unlock_irq(&css_set_lock);
 	}
 
+	if (it->cur_dcset)
+		put_css_set(it->cur_dcset);
+
 	if (it->cur_task)
 		put_task_struct(it->cur_task);
 }
@@ -3830,6 +3872,7 @@ static void *cgroup_procs_start(struct seq_file *s, loff_t *pos)
 	struct kernfs_open_file *of = s->private;
 	struct cgroup *cgrp = seq_css(s)->cgroup;
 	struct css_task_iter *it = of->priv;
+	unsigned iter_flags = CSS_TASK_ITER_PROCS | CSS_TASK_ITER_THREADED;
 
 	/*
 	 * When a seq_file is seeked, it's always traversed sequentially
@@ -3843,10 +3886,10 @@ static void *cgroup_procs_start(struct seq_file *s, loff_t *pos)
 		if (!it)
 			return ERR_PTR(-ENOMEM);
 		of->priv = it;
-		css_task_iter_start(&cgrp->self, CSS_TASK_ITER_PROCS, it);
+		css_task_iter_start(&cgrp->self, iter_flags, it);
 	} else if (!(*pos)++) {
 		css_task_iter_end(it);
-		css_task_iter_start(&cgrp->self, CSS_TASK_ITER_PROCS, it);
+		css_task_iter_start(&cgrp->self, iter_flags, it);
 	}
 
 	return cgroup_procs_next(s, NULL, NULL);
-- 
2.9.3

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

#1689143

On 07/16/2017 10:07 PM, Tejun Heo wrote:
> Hello,
>
> This is v3 of cgroup2 thread mode patchset.  The changes from v2[L]
> are
>
> * Switched to marking each cgroup threaded instead of doing it
>   per-subtree as suggested by PeterZ.  This allows more flexibility
>   and removes certain interface quirks.
>
> * Dropped RFC tag and excluded cpu controller patches from this
>   patchset as threaded mode behaviors can easily be verified with the
>   pid controller.  Will follow up with cpu controller patchset later.
>
> It is largely based on the discussions that we had at the plumbers
> last year.  Here's the rough outline.
>
> * Thread mode is explicitly enabled on a cgroup by writing "threaded"
>   into "cgroup.type" file.  The cgroup shouldn't have any processes or
>   child cgroups.  A threaded cgroup joins the the parent's resource
>   domain and becomes a part of the threaded subtree anchored at the
>   nearest domain ancestor, which is called the threaded domain cgroup
>   of the subtree.
>
> * Threads can be put anywhere in a threaded subtree by writing TIDs
>   into "cgroup.threads" file.  Process granularity and
>   no-internal-process constraint don't apply in a threaded subtree.
>
> * To be used in a threaded subtree, controllers should explicitly
>   declare thread mode support and should be able to handle internal
>   competition in some way.
>
> * The threaded domain cgroup of a threaded subtree serves as the
>   resource domain for the whole subtree.  This is where all the
>   controllers are guaranteed to have a common ground and resource
>   consumptions in the threaded subtree which aren't tied to a specific
>   thread are charged.  Non-threaded controllers never see beyond
>   thread root and can assume that all controllers will follow the same
>   rules upto that point.
>
> * Unlike other cgroups, the system root cgroup can serve as parent to
>   domain child cgroups and threaded domains to threaded subtrees.
>
> This allows threaded controllers to implement thread granular resource
> control without getting in the way of system level resource
> partitioning.
>
> For more details on the interface and behavior, please refer to 0005.
>
> This patchset contains the following six patches.
>
>  0001-cgroup-reorganize-cgroup.procs-task-write-path.patch
>  0002-cgroup-add-flags-to-css_task_iter_start-and-implemen.patch
>  0003-cgroup-introduce-cgroup-dom_cgrp-and-threaded-css_se.patch
>  0004-cgroup-implement-CSS_TASK_ITER_THREADED.patch
>  0005-cgroup-implement-cgroup-v2-thread-support.patch
>  0006-cgroup-update-debug-controller-to-print-out-thread-m.patch
>
> 0001-0005 implement cgroup2 thread mode.  0006 enables debug
> controller on it.
>
> The patchset is based on the current cgroup/for-4.14 27f26753f8c0
> ("cgroup: replace css_set walking populated test with testing
> cgrp->nr_populated_csets") and also available in the following git
> branch.
>
>  git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup.git review-cgroup2-threads-v3

Your new patches don't seem to be pushed to your git tree yet. I
couldn't find them there.

Cheers,
Longman

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

#1689155

On Mon, Jul 17, 2017 at 10:48:44AM -0400, Waiman Long wrote:
> >  git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup.git review-cgroup2-threads-v3
> 
> Your new patches don't seem to be pushed to your git tree yet. I
> couldn't find them there.

Oops, pushed out now.

Thanks.

-- 
tejun

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.kernel

csiph-web