From: "Siddha, Suresh B" <suresh.b.siddha@intel.com>
To: Paul Jackson <pj@sgi.com>
Cc: "Siddha, Suresh B" <suresh.b.siddha@intel.com>,
dino@in.ibm.com, nickpiggin@yahoo.com.au, mbligh@google.com,
akpm@osdl.org, menage@google.com, Simon.Derr@bull.net,
linux-kernel@vger.kernel.org, rohitseth@google.com, holt@sgi.com,
dipankar@in.ibm.com, clameter@sgi.com
Subject: Re: [RFC] cpuset: remove sched domain hooks from cpusets
Date: Sun, 22 Oct 2006 21:31:05 -0700 [thread overview]
Message-ID: <20061022213052.A2526@unix-os.sc.intel.com> (raw)
In-Reply-To: <20061020223738.2919264e.pj@sgi.com>; from pj@sgi.com on Fri, Oct 20, 2006 at 10:37:38PM -0700
On Fri, Oct 20, 2006 at 10:37:38PM -0700, Paul Jackson wrote:
> > And whenever a child cpuset sets this use_cpus_exclusive flag, remove
> > those set of child cpuset cpus from parent cpuset and also from the
> > tasks which were running in the parent cpuset. We can probably allow this
> > to happen as long as parent cpuset has atleast one cpu.
>
> Why are you seeking out obfuscated means and gratuitous entanglements
> with cpuset semantics, in order to accomplish a straight forward end -
> defining the sched domain partitioning?
>
> If we are going to add or modify the meaning of per-cpuset flags in
> order to determine sched domain partitioning, then we should do so in
> the most straight forward way possible, which by all accounts seems to
> be adding a 'sched_domain' flag to each cpuset, indicating whether it
> delineates a sched domain partition. The kernel would enforce a rule
> that the CPUs in the cpusets so marked could not overlap. The kernel
> in return would promise not to split the CPUs in any cpuset so marked
> into more than one sched domain partition, with the consequence that
> the kernel would be able to load balance across all the CPUs contained
> within any such partition.
>
> Why do something less straightforward than that?
Ok. I went to implementation details(and ended up less straight forward..) but
my main intention was to say that we need to retain some sort of hierarchical
shape too, while creating these domain partitions.
Like for example, a big system can be divided into different groups of
cpus for each department in an organisation. And internally based
on the needs, each department can divide its pool of cpus into sub groups
and allocates to much smaller group. And based on the sub group creation/
deletion, cpus will move from department to subgroups and viceversa.
users probably want both flat and hierarchical partitions. And in this
partition mechanism, we should never allow cpus being present in more than one
partition.
thanks,
suresh
next prev parent reply other threads:[~2006-10-23 4:51 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-19 9:23 [RFC] cpuset: remove sched domain hooks from cpusets Paul Jackson
2006-10-19 10:24 ` Nick Piggin
2006-10-19 19:03 ` Paul Jackson
2006-10-19 19:21 ` Nick Piggin
2006-10-19 19:50 ` Martin Bligh
2006-10-20 0:14 ` Paul Jackson
2006-10-20 16:03 ` Nick Piggin
2006-10-20 17:29 ` Siddha, Suresh B
2006-10-20 19:19 ` Paul Jackson
2006-10-20 19:00 ` Paul Jackson
2006-10-20 20:30 ` Dinakar Guniguntala
2006-10-20 21:41 ` Paul Jackson
2006-10-20 22:35 ` Dinakar Guniguntala
2006-10-20 23:14 ` Siddha, Suresh B
2006-10-21 5:37 ` Paul Jackson
2006-10-23 4:31 ` Siddha, Suresh B [this message]
2006-10-23 5:59 ` Paul Jackson
2006-10-21 23:05 ` Paul Jackson
2006-10-22 12:02 ` Paul Jackson
2006-10-23 3:09 ` Paul Jackson
2006-10-20 21:46 ` Paul Jackson
2006-10-21 18:23 ` Paul Menage
2006-10-21 20:55 ` Paul Jackson
2006-10-21 20:59 ` Paul Menage
2006-10-22 10:51 ` Paul Jackson
2006-10-23 5:26 ` Siddha, Suresh B
2006-10-23 5:54 ` Paul Jackson
2006-10-23 5:43 ` Siddha, Suresh B
2006-10-23 6:02 ` Nick Piggin
2006-10-23 6:16 ` Paul Jackson
2006-10-23 16:03 ` Christoph Lameter
2006-11-09 10:59 ` Paul Jackson
2006-10-23 16:01 ` Christoph Lameter
-- strict thread matches above, loose matches on Subject: below --
2006-10-30 21:26 [RFC] cpuset: Remove " Dinakar Guniguntala
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=20061022213052.A2526@unix-os.sc.intel.com \
--to=suresh.b.siddha@intel.com \
--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=nickpiggin@yahoo.com.au \
--cc=pj@sgi.com \
--cc=rohitseth@google.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