From: Rik van Riel <riel@redhat.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: linux-kernel@vger.kernel.org,
Clark Williams <williams@redhat.com>,
Li Zefan <lizefan@huawei.com>, Ingo Molnar <mingo@redhat.com>,
Luiz Capitulino <lcapitulino@redhat.com>,
Mike Galbraith <umgwanakikbuti@gmail.com>,
cgroups@vger.kernel.org
Subject: [PATCH 3/2] cpusets,isolcpus: document relationship between cpusets & isolcpus
Date: Fri, 27 Feb 2015 12:08:03 -0500 [thread overview]
Message-ID: <20150227120803.07db15fe@annuminas.surriel.com> (raw)
In-Reply-To: <20150227093231.GG21418@twins.programming.kicks-ass.net>
Document the subtly changed relationship between cpusets and isolcpus.
Turns out the old documentation did not quite match the code...
Signed-off-by: Rik van Riel <riel@redhat.com>
Suggested-by: Peter Zijlstra <peterz@infradead.org>
---
Documentation/cgroups/cpusets.txt | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/Documentation/cgroups/cpusets.txt b/Documentation/cgroups/cpusets.txt
index f2235a162529..fdf7dff3f607 100644
--- a/Documentation/cgroups/cpusets.txt
+++ b/Documentation/cgroups/cpusets.txt
@@ -392,8 +392,10 @@ Put simply, it costs less to balance between two smaller sched domains
than one big one, but doing so means that overloads in one of the
two domains won't be load balanced to the other one.
-By default, there is one sched domain covering all CPUs, except those
-marked isolated using the kernel boot time "isolcpus=" argument.
+By default, there is one sched domain covering all CPUs, including those
+marked isolated using the kernel boot time "isolcpus=" argument. However,
+the isolated CPUs will not participate in load balancing, and will not
+have tasks running on them unless explicitly assigned.
This default load balancing across all CPUs is not well suited for
the following two situations:
@@ -465,6 +467,10 @@ such partially load balanced cpusets, as they may be artificially
constrained to some subset of the CPUs allowed to them, for lack of
load balancing to the other CPUs.
+CPUs in "cpuset.isolcpus" were excluded from load balancing by the
+isolcpus= kernel boot option, and will never be load balanced regardless
+of the value of "cpuset.sched_load_balance" in any cpuset.
+
1.7.1 sched_load_balance implementation details.
------------------------------------------------
next prev parent reply other threads:[~2015-02-27 17:08 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-25 16:38 [PATCH -v2 0/2] cpusets,isolcpus: resolve conflict between cpusets and isolcpus riel
2015-02-25 16:38 ` [PATCH 1/2] cpusets,isolcpus: exclude isolcpus from load balancing in cpusets riel
2015-02-27 9:32 ` Peter Zijlstra
2015-02-27 17:08 ` Rik van Riel [this message]
2015-02-27 21:15 ` [PATCH 3/2] cpusets,isolcpus: document relationship between cpusets & isolcpus David Rientjes
2015-02-28 3:23 ` Zefan Li
2015-02-28 3:21 ` [PATCH 1/2] cpusets,isolcpus: exclude isolcpus from load balancing in cpusets Zefan Li
2015-02-25 16:38 ` [PATCH 2/2] cpusets,isolcpus: add file to show isolated cpus in cpuset riel
2015-02-25 21:09 ` David Rientjes
2015-02-25 21:21 ` Rik van Riel
2015-02-25 21:32 ` [PATCH v3 " Rik van Riel
2015-02-26 11:05 ` [PATCH " Zefan Li
2015-02-26 15:24 ` Rik van Riel
2015-02-26 17:12 ` [PATCH v4 " Rik van Riel
2015-02-28 3:22 ` Zefan Li
2015-03-02 6:15 ` Zefan Li
2015-03-02 9:12 ` Peter Zijlstra
2015-03-03 9:51 ` Zefan Li
2015-03-02 9:09 ` Peter Zijlstra
2015-03-02 12:44 ` Mike Galbraith
2015-03-02 14:35 ` Rik van Riel
2015-03-02 14:54 ` Mike Galbraith
2015-03-02 15:29 ` Tejun Heo
2015-03-02 16:02 ` Mike Galbraith
2015-03-02 16:09 ` Tejun Heo
2015-03-02 17:35 ` Mike Galbraith
2015-03-02 17:01 ` Tejun Heo
2015-03-02 17:31 ` Tejun Heo
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=20150227120803.07db15fe@annuminas.surriel.com \
--to=riel@redhat.com \
--cc=cgroups@vger.kernel.org \
--cc=lcapitulino@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lizefan@huawei.com \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=umgwanakikbuti@gmail.com \
--cc=williams@redhat.com \
/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®