summaryrefslogtreecommitdiff
path: root/lib/bitmap.c
diff options
context:
space:
mode:
authorPaul Jackson <pj@sgi.com>2005-10-30 15:02:32 -0800
committerLinus Torvalds <torvalds@g5.osdl.org>2005-10-30 17:37:21 -0800
commit28a42b9ea7e42e1efb02cc2dcacba0b6af234e1b (patch)
tree1415acfeec32553888f870eb5c0debc370e1d3b7 /lib/bitmap.c
parent18a19cb3047e454ee5ecbc35d7acf3f8e09e0466 (diff)
[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/bitmap.c')
0 files changed, 0 insertions, 0 deletions