From: Paul Jackson <pj@sgi.com>
To: Andrew Morton <akpm@osdl.org>
Cc: Simon.Derr@bull.net, Paul Jackson <pj@sgi.com>,
linux-kernel@vger.kernel.org,
Christoph Lameter <clameter@sgi.com>,
Linus Torvalds <torvalds@osdl.org>
Subject: [PATCH] cpuset confine pdflush to its cpuset
Date: Sun, 23 Oct 2005 17:19:13 -0700 (PDT) [thread overview]
Message-ID: <20051024001913.7030.71597.sendpatchset@jackhammer.engr.sgi.com> (raw)
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>
---
mm/pdflush.c | 13 +++++++++++++
1 files changed, 13 insertions(+)
--- 2.6.14-rc4-mm1-cpuset-patches.orig/mm/pdflush.c 2005-10-17 22:39:41.033879927 -0700
+++ 2.6.14-rc4-mm1-cpuset-patches/mm/pdflush.c 2005-10-23 17:17:03.720802617 -0700
@@ -20,6 +20,7 @@
#include <linux/fs.h> // Needed by writeback.h
#include <linux/writeback.h> // Prototypes pdflush_operation()
#include <linux/kthread.h>
+#include <linux/cpuset.h>
/*
@@ -170,12 +171,24 @@ static int __pdflush(struct pdflush_work
static int pdflush(void *dummy)
{
struct pdflush_work my_work;
+ cpumask_t cpus_allowed;
/*
* pdflush can spend a lot of time doing encryption via dm-crypt. We
* don't want to do that at keventd's priority.
*/
set_user_nice(current, 0);
+
+ /*
+ * Some configs put our parent kthread in a limited cpuset,
+ * which kthread() overrides, forcing cpus_allowed == CPU_MASK_ALL.
+ * Our needs are more modest - cut back to our cpusets cpus_allowed.
+ * This is needed as pdflush's are dynamically created and destroyed.
+ * The boottime pdflush's are easily placed w/o these 2 lines.
+ */
+ cpus_allowed = cpuset_cpus_allowed(current);
+ set_cpus_allowed(current, cpus_allowed);
+
return __pdflush(&my_work);
}
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@sgi.com> 1.650.933.1373
next reply other threads:[~2005-10-24 0:19 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-10-24 0:19 Paul Jackson [this message]
2005-10-24 5:52 ` [PATCH] cpuset confine pdflush to its cpuset Hirokazu Takahashi
2005-10-24 6:32 ` Paul Jackson
2005-10-24 6:40 ` Andrew Morton
2005-10-24 6:49 ` Paul Jackson
2005-10-24 7:13 ` Hirokazu Takahashi
2005-10-24 7:37 ` Paul Jackson
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=20051024001913.7030.71597.sendpatchset@jackhammer.engr.sgi.com \
--to=pj@sgi.com \
--cc=Simon.Derr@bull.net \
--cc=akpm@osdl.org \
--cc=clameter@sgi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@osdl.org \
/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