diff options
author | Paul Jackson <pj@sgi.com> | 2005-10-30 15:02:32 -0800 |
---|---|---|
committer | Linus Torvalds <torvalds@g5.osdl.org> | 2005-10-30 17:37:21 -0800 |
commit | 28a42b9ea7e42e1efb02cc2dcacba0b6af234e1b (patch) | |
tree | 1415acfeec32553888f870eb5c0debc370e1d3b7 /lib | |
parent | 18a19cb3047e454ee5ecbc35d7acf3f8e09e0466 (diff) | |
download | linux-3.10-28a42b9ea7e42e1efb02cc2dcacba0b6af234e1b.tar.gz linux-3.10-28a42b9ea7e42e1efb02cc2dcacba0b6af234e1b.tar.bz2 linux-3.10-28a42b9ea7e42e1efb02cc2dcacba0b6af234e1b.zip |
[PATCH] cpusets: confine pdflush to its cpuset
This patch keeps pdflush daemons on the same cpuset as their parent, the
kthread daemon.
Some large NUMA configurations put as much as they can of kernel threads
and other classic Unix load in what's called a bootcpuset, keeping the rest
of the system free for dedicated jobs.
This effort is thwarted by pdflush, which dynamically destroys and
recreates pdflush daemons depending on load.
It's easy enough to force the originally created pdflush deamons into the
bootcpuset, at system boottime. But the pdflush threads created later were
allowed to run freely across the system, due to the necessary line in their
startup kthread():
set_cpus_allowed(current, CPU_MASK_ALL);
By simply coding pdflush to start its threads with the cpus_allowed
restrictions of its cpuset (inherited from kthread, its parent) we can
ensure that dynamically created pdflush threads are also kept in the
bootcpuset.
On systems w/o cpusets, or w/o a bootcpuset implementation, the following
will have no affect, leaving pdflush to run on any CPU, as before.
Signed-off-by: Paul Jackson <pj@sgi.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Diffstat (limited to 'lib')
0 files changed, 0 insertions, 0 deletions