From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Paul Jackson <pj@sgi.com>
Cc: akpm@osdl.org, mbligh@google.com, menage@google.com,
Simon.Derr@bull.net, linux-kernel@vger.kernel.org,
dino@in.ibm.com, rohitseth@google.com, holt@sgi.com,
dipankar@in.ibm.com, suresh.b.siddha@intel.com, clameter@sgi.com
Subject: Re: [RFC] cpuset: add interface to isolated cpus
Date: Sat, 21 Oct 2006 20:51:08 +1000 [thread overview]
Message-ID: <4539FB9C.10204@yahoo.com.au> (raw)
In-Reply-To: <20061021002400.fb25f327.pj@sgi.com>
Paul Jackson wrote:
>>If you always have other domains overlapping them (regardless
>>that it is a parent), then what actual use does cpu_exclusive
>>flag have?
>
>
> Good question. To be a tad too honest, I don't consider it to be
> all that essential.
>
> It does turn out to be a bit useful, in that you can be confident that
> if you are administering the batch scheduler and it has a cpu_exclusive
> cpuset covering a big chunk of your system, then no other cpuset other
> than the top cpuset right above, which you administer pretty tightly,
> could have anything overlapping it. You don't have to actually look
> at the cpumasks in all the parallel cpusets and cross check each one
> against the batch schedulers set of cpus for overlap.
>
> But as you can see by grep'ing in kernel/cpuset.c, it is only used
> to generate a couple of error returns, for things that you can do
> just fine by turning off the cpu_exclusive flag.
Well, it was supposed to be used for sched-domains partitioning, and
its uselessness for anything else I guess is what threw me.
But even the way cpu_exclusive semantics are defined makes it not
quite compatible with partitioning anyway, unfortunately.
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
next prev parent reply other threads:[~2006-10-21 10:51 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-19 9:26 [RFC] cpuset: add interface to isolated cpus Paul Jackson
2006-10-19 10:17 ` Nick Piggin
2006-10-19 17:55 ` Paul Jackson
2006-10-19 18:07 ` Nick Piggin
2006-10-19 18:56 ` Paul Jackson
2006-10-19 19:03 ` Nick Piggin
2006-10-20 3:37 ` Paul Jackson
2006-10-20 8:02 ` Nick Piggin
2006-10-20 14:52 ` Nick Piggin
2006-10-20 20:03 ` Paul Jackson
2006-10-20 19:59 ` Paul Jackson
2006-10-20 20:01 ` Paul Jackson
2006-10-20 20:59 ` Siddha, Suresh B
2006-10-21 1:33 ` Paul Jackson
2006-10-21 6:14 ` Nick Piggin
2006-10-21 7:24 ` Paul Jackson
2006-10-21 10:51 ` Nick Piggin [this message]
2006-10-22 4:54 ` Paul Jackson
2006-10-20 21:04 ` Dinakar Guniguntala
2006-10-23 3:18 ` Paul Jackson
2006-10-23 5:07 ` Nick Piggin
2006-10-23 5:51 ` Paul Jackson
2006-10-23 5:40 ` Siddha, Suresh B
2006-10-23 6:06 ` Paul Jackson
2006-10-23 6:07 ` Paul Jackson
2006-10-23 6:17 ` Nick Piggin
2006-10-23 6:41 ` Paul Jackson
2006-10-23 6:49 ` Nick Piggin
2006-10-23 6:48 ` Paul Jackson
2006-10-23 20:58 ` Paul Jackson
2006-10-23 19:50 ` Dinakar Guniguntala
2006-10-23 20:47 ` Paul Jackson
2006-10-24 15:44 ` Paul Jackson
2006-10-25 19:40 ` 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=4539FB9C.10204@yahoo.com.au \
--to=nickpiggin@yahoo.com.au \
--cc=Simon.Derr@bull.net \
--cc=akpm@osdl.org \
--cc=clameter@sgi.com \
--cc=dino@in.ibm.com \
--cc=dipankar@in.ibm.com \
--cc=holt@sgi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mbligh@google.com \
--cc=menage@google.com \
--cc=pj@sgi.com \
--cc=rohitseth@google.com \
--cc=suresh.b.siddha@intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.