[PATCH] cpusets: confine pdflush to its cpuset
commit28a42b9ea7e42e1efb02cc2dcacba0b6af234e1b
authorPaul Jackson <pj@sgi.com>
Sun, 30 Oct 2005 23:02:32 +0000 (30 15:02 -0800)
committerLinus Torvalds <torvalds@g5.osdl.org>
Mon, 31 Oct 2005 01:37:21 +0000 (30 17:37 -0800)
tree1415acfeec32553888f870eb5c0debc370e1d3b7
parent18a19cb3047e454ee5ecbc35d7acf3f8e09e0466
[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>
mm/pdflush.c