From: Waiman Long <longman@redhat.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Tejun Heo <tj@kernel.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, kernel-team@fb.com, pjt@google.com,
luto@amacapital.net, Mike Galbraith <efault@gmx.de>,
torvalds@linux-foundation.org, Roman Gushchin <guro@fb.com>,
Juri Lelli <juri.lelli@redhat.com>
Subject: Re: [PATCH v7 2/5] cpuset: Add cpuset.sched_load_balance to v2
Date: Wed, 2 May 2018 09:29:54 -0400 [thread overview]
Message-ID: <14d7604c-1254-1146-e2b6-23f4cc020b34@redhat.com> (raw)
In-Reply-To: <20180502102416.GJ12180@hirez.programming.kicks-ass.net>
On 05/02/2018 06:24 AM, Peter Zijlstra wrote:
> On Thu, Apr 19, 2018 at 09:47:01AM -0400, Waiman Long wrote:
>> + cpuset.sched_load_balance
>> + A read-write single value file which exists on non-root cgroups.
> Uhhm.. it should very much exist in the root group too. Otherwise you
> cannot disable it there, which is required to allow smaller groups to
> load-balance between themselves.
>
>> + The default is "1" (on), and the other possible value is "0"
>> + (off).
>> +
>> + When it is on, tasks within this cpuset will be load-balanced
>> + by the kernel scheduler. Tasks will be moved from CPUs with
>> + high load to other CPUs within the same cpuset with less load
>> + periodically.
>> +
>> + When it is off, there will be no load balancing among CPUs on
>> + this cgroup. Tasks will stay in the CPUs they are running on
>> + and will not be moved to other CPUs.
>> +
>> + This flag is hierarchical and is inherited by child cpusets. It
>> + can be turned off only when the CPUs in this cpuset aren't
>> + listed in the cpuset.cpus of other sibling cgroups, and all
>> + the child cpusets, if present, have this flag turned off.
>> +
>> + Once it is off, it cannot be turned back on as long as the
>> + parent cgroup still has this flag in the off state.
> That too is wrong and broken. You explicitly want to turn it on for
> children.
>
> So the idea is that you can have:
>
> R
> / \
> A B
>
> With:
>
> R cpus=0-3, load_balance=0
> A cpus=0-1, load_balance=1
> B cpus=2-3, load_balance=1
>
> Which will allow all tasks in A,B (and its children) to load-balance
> across 0-1 or 2-3 resp.
>
> If you don't allow the root group to disable load_balance, it will
> always be the largest group and load-balancing will always happen system
> wide.
If you look at the remaining patches in the series, I was proposing a
different way to support isolcpus and separate sched domains with
turning off load balancing in the root cgroup.
For me, it doesn't feel right to have load balancing disabled in the
root cgroup as we probably cannot move all the tasks away from the root
cgroup anyway. I am going to update the current patchset to incorporate
suggestion from Tejun. It will probably be ready sometime next week.
Cheers,
Longman
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2018-05-02 13:36 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-19 13:46 [PATCH v7 0/5] cpuset: Enable cpuset controller in default hierarchy Waiman Long
2018-04-19 13:47 ` [PATCH v7 1/5] " Waiman Long
2018-04-19 13:47 ` [PATCH v7 2/5] cpuset: Add cpuset.sched_load_balance to v2 Waiman Long
2018-05-02 10:24 ` Peter Zijlstra
2018-05-02 13:29 ` Waiman Long [this message]
2018-05-02 13:42 ` Peter Zijlstra
2018-05-02 13:47 ` Waiman Long
2018-05-02 14:02 ` Peter Zijlstra
2018-05-02 14:35 ` Mike Galbraith
2018-04-19 13:47 ` [PATCH v7 3/5] cpuset: Add a root-only cpus.isolated v2 control file Waiman Long
2018-04-23 15:56 ` Juri Lelli
2018-05-02 14:08 ` Peter Zijlstra
2018-05-08 0:30 ` Waiman Long
2018-04-19 13:47 ` [PATCH v7 4/5] cpuset: Restrict load balancing off cpus to subset of cpus.isolated Waiman Long
2018-05-01 19:51 ` Tejun Heo
2018-05-01 20:33 ` Waiman Long
2018-05-01 20:58 ` Tejun Heo
2018-05-01 21:31 ` Waiman Long
2018-04-19 13:47 ` [PATCH v7 5/5] cpuset: Make generate_sched_domains() recognize isolated_cpus Waiman Long
2018-04-20 8:23 ` [PATCH v7 0/5] cpuset: Enable cpuset controller in default hierarchy Mike Galbraith
2018-04-23 16:32 ` Waiman Long
2018-04-23 13:07 ` Juri Lelli
2018-04-23 13:57 ` Juri Lelli
2018-04-23 14:10 ` 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=14d7604c-1254-1146-e2b6-23f4cc020b34@redhat.com \
--to=longman@redhat.com \
--cc=cgroups@vger.kernel.org \
--cc=efault@gmx.de \
--cc=guro@fb.com \
--cc=hannes@cmpxchg.org \
--cc=juri.lelli@redhat.com \
--cc=kernel-team@fb.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.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 \
--cc=torvalds@linux-foundation.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;
as well as URLs for NNTP newsgroup(s).