From: Paul Jackson <pj@sgi.com>
To: vatsa@linux.vnet.ibm.com
Cc: mingo@elte.hu, clameter@sgi.com, linux-kernel@vger.kernel.org,
dino@in.ibm.com, akpm@linux-foundation.org
Subject: Re: cpuset attach_task to touch per-cpu kernel threads?
Date: Fri, 22 Jun 2007 10:41:38 -0700 [thread overview]
Message-ID: <20070622104138.9c23e1f1.pj@sgi.com> (raw)
In-Reply-To: <20070622171634.GA21543@linux.vnet.ibm.com>
Srivatsa wrote:
> That again is not fool-proof. What if kernel-tasks change their cpu affinity
> after we have done the is_pinned_kernel_thread() test? Ideally they
> should not, but one never knows!
>
> IMHO we simply should not allow kernel threads to move out of top-cpuset
Well ... in some theoretical world, perhaps.
In reality, there a big pile of kernel threads that we want to move out
of the root cpuset. And in reality, kernel threads don't change from
being unrestricted (all cpus allowed) to being pinned (to some specific
subset of cpus). Kernel threads that need to be pinned know it up
front; it's an essential part of whatever they do.
I've been working with installed customer configurations for about two
and a half years now that move unpinned kernel threads out of the top
cpuset, as part of keeping portions of the system freed up for dedicated
jobs. I cannot agree to removing this capability.
Nack.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@sgi.com> 1.925.600.0401
prev parent reply other threads:[~2007-06-22 17:41 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-21 1:49 cpuset attach_task to touch per-cpu kernel threads? Srivatsa Vaddagiri
2007-06-21 2:35 ` Paul Jackson
2007-06-21 12:16 ` Ingo Molnar
2007-06-21 17:07 ` Paul Jackson
2007-06-21 17:32 ` Srivatsa Vaddagiri
2007-06-21 17:51 ` Paul Jackson
2007-06-22 17:16 ` Srivatsa Vaddagiri
2007-06-22 17:41 ` Paul Jackson [this message]
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=20070622104138.9c23e1f1.pj@sgi.com \
--to=pj@sgi.com \
--cc=akpm@linux-foundation.org \
--cc=clameter@sgi.com \
--cc=dino@in.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=vatsa@linux.vnet.ibm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox