From: Dinakar Guniguntala <dino@in.ibm.com>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: Paul Jackson <pj@sgi.com>,
Simon.Derr@bull.net, lkml <linux-kernel@vger.kernel.org>,
lse-tech@lists.sourceforge.net, Andrew Morton <akpm@osdl.org>,
dipankar@in.ibm.com, colpatch@us.ibm.com
Subject: Re: [RFC PATCH] Dynamic sched domains aka Isolated cpusets
Date: Tue, 19 Apr 2005 15:22:30 +0530 [thread overview]
Message-ID: <20050419095230.GC3963@in.ibm.com> (raw)
In-Reply-To: <1113891575.5074.46.camel@npiggin-nld.site>
On Tue, Apr 19, 2005 at 04:19:35PM +1000, Nick Piggin wrote:
[...Snip...]
> Though I imagine this becomes a complete superset of the
> isolcpus= functionality, and it would actually be easier to
> manage a single isolated CPU and its associated processes with
> the cpusets interfaces after this.
That is the idea, though I think that we need to be able to
provide users the option of not doing a load balance within a
sched domain
> It doesn't work if you have *most* jobs bound to either
> {0, 1, 2, 3} or {4, 5, 6, 7} but one which should be allowed
> to use any CPU from 0-7.
That is the current definition of cpu_exclusive on cpusets.
I initially thought of attaching exclusive cpusets to sched domains,
but that would not work because of this reason
> >
> > In the case of cpus, we really do prefer the partitions to be
> > disjoint, because it would be better not to confuse the domain
> > scheduler with overlapping domains.
> >
>
> Yes. The domain scheduler can't handle this at all, it would
> have to fall back on cpus_allowed, which in turn can create
> big problems for multiprocessor balancing.
>
I agree
> >From what I gather, this partitioning does not exactly fit
> the cpusets architecture. Because with cpusets you are specifying
> on what cpus can a set of tasks run, not dividing the whole system.
Since isolated cpusets are trying to partition the system, this
can be restricted to only the first level of cpusets. Keeping in mind
that we have a flat sched domain heirarchy, I think probably this
would simplify the update_sched_domains function quite a bit.
Also I think we can add further restrictions in terms not being able
to change (add/remove) cpus within a isolated cpuset. Instead one would
have to tear down an existing cpuset and make a new one with the
required configuration. that would simplify things even further
> The sched-domains setup code will take care of all that for you
> already. It won't know or care about the partitions. If you
> partition a 64-way system into 2 32-ways, the domain setup code
> will just think it is setting up a 32-way system.
>
> Don't worry about the sched-domains side of things at all, that's
> pretty easy. Basically you just have to know that it has the
> capability to partition the system in an arbitrary disjoint set
> of sets of cpus.
And maybe also have a flag that says whether to have load balancing
in this domain or not
-Dinakar
next prev parent reply other threads:[~2005-04-19 9:34 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-07 0:51 [RFC PATCH] scheduler: Dynamic sched_domains Matthew Dobson
2004-10-07 2:13 ` Nick Piggin
2004-10-07 17:01 ` Jesse Barnes
2004-10-08 5:55 ` [Lse-tech] " Takayoshi Kochi
2004-10-08 6:08 ` Nick Piggin
2004-10-08 16:43 ` Jesse Barnes
2004-10-07 21:58 ` Matthew Dobson
2004-10-08 0:22 ` Nick Piggin
2004-10-07 22:20 ` Matthew Dobson
2004-10-07 4:12 ` [ckrm-tech] " Marc E. Fiuczynski
2004-10-07 5:35 ` Paul Jackson
2004-10-07 22:06 ` Matthew Dobson
2004-10-07 9:32 ` Paul Jackson
2004-10-08 10:14 ` [Lse-tech] " Erich Focht
2004-10-08 10:40 ` Nick Piggin
2004-10-08 15:50 ` [ckrm-tech] " Hubertus Franke
2004-10-08 22:48 ` Matthew Dobson
2004-10-08 18:54 ` Matthew Dobson
2004-10-08 21:56 ` Peter Williams
2004-10-08 22:52 ` Matthew Dobson
2004-10-08 23:13 ` Erich Focht
2004-10-08 23:50 ` Nick Piggin
2004-10-10 12:25 ` Erich Focht
2004-10-08 22:51 ` Erich Focht
2004-10-09 1:05 ` Matthew Dobson
2004-10-10 12:45 ` Erich Focht
2004-10-12 22:45 ` Matthew Dobson
2004-10-08 18:45 ` Matthew Dobson
2005-04-18 20:26 ` [RFC PATCH] Dynamic sched domains aka Isolated cpusets Dinakar Guniguntala
2005-04-18 23:44 ` Nick Piggin
2005-04-19 8:00 ` Dinakar Guniguntala
2005-04-19 5:54 ` Paul Jackson
2005-04-19 6:19 ` Nick Piggin
2005-04-19 6:59 ` Paul Jackson
2005-04-19 7:09 ` Nick Piggin
2005-04-19 7:25 ` Paul Jackson
2005-04-19 7:28 ` Paul Jackson
2005-04-19 7:19 ` Paul Jackson
2005-04-19 7:57 ` Nick Piggin
2005-04-19 20:34 ` Paul Jackson
2005-04-23 23:26 ` Paul Jackson
2005-04-26 0:52 ` Matthew Dobson
2005-04-26 0:59 ` Paul Jackson
2005-04-19 9:52 ` Dinakar Guniguntala [this message]
2005-04-19 15:26 ` Paul Jackson
2005-04-20 7:37 ` Dinakar Guniguntala
2005-04-19 20:42 ` Paul Jackson
2005-04-19 8:12 ` Simon Derr
2005-04-19 16:19 ` Paul Jackson
2005-04-19 9:34 ` [Lse-tech] " Dinakar Guniguntala
2005-04-19 17:23 ` Paul Jackson
2005-04-20 7:16 ` Dinakar Guniguntala
2005-04-20 19:09 ` Paul Jackson
2005-04-21 16:27 ` Dinakar Guniguntala
2005-04-22 21:26 ` Paul Jackson
2005-04-23 7:24 ` Dinakar Guniguntala
2005-04-23 22:30 ` Paul Jackson
2005-04-25 11:53 ` Dinakar Guniguntala
2005-04-25 14:38 ` Paul Jackson
2005-04-21 17:31 ` [RFC PATCH] Dynamic sched domains aka Isolated cpusets (v0.2) Dinakar Guniguntala
2005-04-22 18:50 ` Paul Jackson
2005-04-22 21:37 ` Paul Jackson
2005-04-23 3:11 ` 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=20050419095230.GC3963@in.ibm.com \
--to=dino@in.ibm.com \
--cc=Simon.Derr@bull.net \
--cc=akpm@osdl.org \
--cc=colpatch@us.ibm.com \
--cc=dipankar@in.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lse-tech@lists.sourceforge.net \
--cc=nickpiggin@yahoo.com.au \
--cc=pj@sgi.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