From: Waiman Long <longman@redhat.com>
To: Tejun Heo <tj@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
Li Zefan <lizefan@huawei.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Ingo Molnar <mingo@redhat.com>,
cgroups@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-doc@vger.kernel.org, linux-mm@kvack.org,
kernel-team@fb.com, pjt@google.com, luto@amacapital.net,
efault@gmx.de
Subject: Re: [RFC PATCH v2 11/17] cgroup: Implement new thread mode semantics
Date: Fri, 2 Jun 2017 16:36:22 -0400 [thread overview]
Message-ID: <cf47d637-204c-49ea-94ec-c2bf0cf10614@redhat.com> (raw)
In-Reply-To: <20170601211823.GC13390@htj.duckdns.org>
On 06/01/2017 05:18 PM, Tejun Heo wrote:
> Hello,
>
> On Thu, Jun 01, 2017 at 05:12:42PM -0400, Waiman Long wrote:
>> Are you referring to keeping the no internal process restriction and
>> document how to work around that instead? I would like to hear what
>> workarounds are currently being used.
> What we've been talking about all along - just creating explicit leaf
> nodes.
>
>> Anyway, you currently allow internal process in thread mode, but not in
>> non-thread mode. I would prefer no such restriction in both thread and
>> non-thread mode.
> Heh, so, these aren't arbitrary. The contraint is tied to
> implementing resource domains and thread subtree doesn't have resource
> domains in them, so they don't need the constraint. I'm sorry about
> the short replies but I'm kinda really tied up right now. I'm gonna
> do the thread mode so that it can be agnostic w.r.t. the internal
> process constraint and I think it could be helpful to decouple these
> discussions. We've been having this discussion for a couple years now
> and it looks like we're gonna go through it all over, which is fine,
> but let's at least keep that separate.
I wouldn't argue further on that if you insist. However, I still want to
relax the constraint somewhat by abandoning the no internal process
constraint when only threaded controllers (non-resource domains) are
enabled even when thread mode has not been explicitly enabled. It is a
modified version my second alternative. Now the question is which
controllers are considered to be resource domains. I think memory and
blkio are in the list. What else do you think should be considered
resource domains?
Cheers,
Longman
any of the resource domains (!threaded) controllers are enabled.
next prev parent reply other threads:[~2017-06-02 20:36 UTC|newest]
Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-15 13:33 [RFC PATCH v2 00/17] cgroup: Major changes to cgroup v2 core Waiman Long
2017-05-15 13:34 ` [RFC PATCH v2 01/17] cgroup: reorganize cgroup.procs / task write path Waiman Long
2017-05-15 13:34 ` [RFC PATCH v2 02/17] cgroup: add @flags to css_task_iter_start() and implement CSS_TASK_ITER_PROCS Waiman Long
2017-05-15 13:34 ` [RFC PATCH v2 03/17] cgroup: introduce cgroup->proc_cgrp and threaded css_set handling Waiman Long
2017-05-15 13:34 ` [RFC PATCH v2 04/17] cgroup: implement CSS_TASK_ITER_THREADED Waiman Long
2017-05-15 13:34 ` [RFC PATCH v2 05/17] cgroup: implement cgroup v2 thread support Waiman Long
2017-05-15 13:34 ` [RFC PATCH v2 06/17] cgroup: Fix reference counting bug in cgroup_procs_write() Waiman Long
2017-05-17 19:20 ` Tejun Heo
2017-05-15 13:34 ` [RFC PATCH v2 07/17] cgroup: Prevent kill_css() from being called more than once Waiman Long
2017-05-17 19:23 ` Tejun Heo
2017-05-17 20:24 ` Waiman Long
2017-05-17 21:34 ` Tejun Heo
2017-05-15 13:34 ` [RFC PATCH v2 08/17] cgroup: Move debug cgroup to its own file Waiman Long
2017-05-17 21:36 ` Tejun Heo
2017-05-18 15:29 ` Waiman Long
2017-05-18 15:52 ` Waiman Long
2017-05-19 19:21 ` Tejun Heo
2017-05-19 19:33 ` Waiman Long
2017-05-19 20:28 ` Tejun Heo
2017-05-15 13:34 ` [RFC PATCH v2 09/17] cgroup: Keep accurate count of tasks in each css_set Waiman Long
2017-05-17 21:40 ` Tejun Heo
2017-05-18 15:56 ` Waiman Long
2017-05-15 13:34 ` [RFC PATCH v2 10/17] cgroup: Make debug cgroup support v2 and thread mode Waiman Long
2017-05-17 21:43 ` Tejun Heo
2017-05-18 15:58 ` Waiman Long
2017-05-15 13:34 ` [RFC PATCH v2 11/17] cgroup: Implement new thread mode semantics Waiman Long
2017-05-17 21:47 ` Tejun Heo
2017-05-18 17:21 ` Waiman Long
2017-05-19 20:26 ` Tejun Heo
2017-05-19 20:58 ` Tejun Heo
2017-05-22 17:13 ` Waiman Long
2017-05-22 17:32 ` Waiman Long
2017-05-24 20:36 ` Tejun Heo
2017-05-24 21:17 ` Waiman Long
2017-05-24 21:27 ` Tejun Heo
2017-06-01 14:50 ` Tejun Heo
2017-06-01 15:10 ` Peter Zijlstra
2017-06-01 15:35 ` Tejun Heo
2017-06-01 18:44 ` Waiman Long
2017-06-01 18:47 ` Tejun Heo
2017-06-01 19:27 ` Waiman Long
2017-06-01 20:38 ` Tejun Heo
2017-06-01 20:48 ` Waiman Long
2017-06-01 20:52 ` Tejun Heo
2017-06-01 21:12 ` Waiman Long
2017-06-01 21:18 ` Tejun Heo
2017-06-02 20:36 ` Waiman Long [this message]
2017-06-03 10:33 ` Tejun Heo
2017-06-01 19:55 ` Waiman Long
2017-06-01 20:15 ` Waiman Long
2017-06-01 18:41 ` Waiman Long
2017-05-15 13:34 ` [RFC PATCH v2 12/17] cgroup: Remove cgroup v2 no internal process constraint Waiman Long
2017-05-19 20:38 ` Tejun Heo
2017-05-20 2:10 ` Mike Galbraith
2017-05-24 17:01 ` Tejun Heo
2017-05-22 16:56 ` Waiman Long
2017-05-24 17:05 ` Tejun Heo
2017-05-24 18:19 ` Waiman Long
2017-05-15 13:34 ` [RFC PATCH v2 13/17] cgroup: Allow fine-grained controllers control in cgroup v2 Waiman Long
2017-05-19 20:55 ` Tejun Heo
2017-05-19 21:20 ` Waiman Long
2017-05-24 17:31 ` Tejun Heo
2017-05-24 17:49 ` Waiman Long
2017-05-24 17:56 ` Tejun Heo
2017-05-24 18:17 ` Waiman Long
2017-05-15 13:34 ` [RFC PATCH v2 14/17] cgroup: Enable printing of v2 controllers' cgroup hierarchy Waiman Long
2017-05-15 13:34 ` [RFC PATCH v2 15/17] sched: Misc preps for cgroup unified hierarchy interface Waiman Long
2017-05-15 13:34 ` [RFC PATCH v2 16/17] sched: Implement interface for cgroup unified hierarchy Waiman Long
2017-05-15 13:34 ` [RFC PATCH v2 17/17] sched: Make cpu/cpuacct threaded controllers Waiman Long
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cf47d637-204c-49ea-94ec-c2bf0cf10614@redhat.com \
--to=longman@redhat.com \
--cc=cgroups@vger.kernel.org \
--cc=efault@gmx.de \
--cc=hannes@cmpxchg.org \
--cc=kernel-team@fb.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lizefan@huawei.com \
--cc=luto@amacapital.net \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=pjt@google.com \
--cc=tj@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®