From: Li Zefan <lizf@cn.fujitsu.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Paul Jackson <pj@sgi.com>, Paul Menage <menage@google.com>,
LKML <linux-kernel@vger.kernel.org>
Subject: [PATCH] cpuset: hotplug documentation fix
Date: Fri, 05 Sep 2008 11:43:52 +0800 [thread overview]
Message-ID: <48C0AAF8.605@cn.fujitsu.com> (raw)
If all the cpus/mems in a cpuset are offlined, the tasks in it will
be moved to the nearest ancestor with non-empty cpus/mems.
Signed-off-by: Li Zefan <lizf@cn.fujitsu.com>
---
Documentation/cpusets.txt | 18 ++++++++++--------
1 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/Documentation/cpusets.txt b/Documentation/cpusets.txt
index 1f5a924..871c1dd 100644
--- a/Documentation/cpusets.txt
+++ b/Documentation/cpusets.txt
@@ -635,14 +635,16 @@ prior 'mems' setting, will not be moved.
There is an exception to the above. If hotplug functionality is used
to remove all the CPUs that are currently assigned to a cpuset,
-then the kernel will automatically update the cpus_allowed of all
-tasks attached to CPUs in that cpuset to allow all CPUs. When memory
-hotplug functionality for removing Memory Nodes is available, a
-similar exception is expected to apply there as well. In general,
-the kernel prefers to violate cpuset placement, over starving a task
-that has had all its allowed CPUs or Memory Nodes taken offline. User
-code should reconfigure cpusets to only refer to online CPUs and Memory
-Nodes when using hotplug to add or remove such resources.
+then all the tasks in that cpuset will be moved to the nearest ancestor
+with non-empty cpus. But the moving of some (or all) tasks might fail if
+cpuset is binded with another cgroup subsystem which has some restrictions
+on task attaching. In this failing case, those tasks will stay
+in the original cpuset, and the kernel will automatically update
+their cpus_allowed to allow all online CPUs. When memory hotplug
+functionality for removing Memory Nodes is available, a similar exception
+is expected to apply there as well. In general, the kernel prefers to
+violate cpuset placement, over starving a task that has had all
+its allowed CPUs or Memory Nodes taken offline.
There is a second exception to the above. GFP_ATOMIC requests are
kernel internal allocations that must be satisfied, immediately.
--
1.5.4.rc3
next reply other threads:[~2008-09-05 3:44 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-05 3:43 Li Zefan [this message]
2008-09-05 4:29 ` [PATCH] cpuset: hotplug documentation fix Paul Jackson
2008-09-05 5:08 ` Li Zefan
2008-09-05 5:18 ` Paul Jackson
2008-09-05 5:12 ` [PATCH -v2] " Li Zefan
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=48C0AAF8.605@cn.fujitsu.com \
--to=lizf@cn.fujitsu.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=menage@google.com \
--cc=pj@sgi.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.