All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Jesse Barnes <jbarnes@engr.sgi.com>
Cc: Dimitri Sivanich <sivanich@sgi.com>,
	linux-kernel@vger.kernel.org, John Hawkes <hawkes@sgi.com>
Subject: Re: [RFC] Patch for isolated scheduler domains
Date: Sun, 25 Jul 2004 14:26:47 +1000	[thread overview]
Message-ID: <41033687.4080304@yahoo.com.au> (raw)
In-Reply-To: <200407241140.29453.jbarnes@engr.sgi.com>

Jesse Barnes wrote:
> On Saturday, July 24, 2004 1:26 am, Nick Piggin wrote:
> 
>>You might have the theoretical problem of ending up with more than
>>one disjoint top level domain (ie. no overlap, basically partitioning
>>the CPUs).
> 
> 
> Yes, we'll have several disjoint per-node cpu spans for a large system, but 
> nearby nodes *will* overlap with more distant nodes than any given node, so I 
> think we're covered, unless I'm misunderstanding something.
> 

No, I'm sure you are covered. The situation I thought of would be
something like the following:

CPUs 0-63, all within distance 4 --- gap distance 5 --- CPUs 64-127.

Where you wouldn't have any overlap between the two sets of CPUs.
This is probably not applicable to you though.

> 
>>No doubt you could come up with something provably correct, however
>>it might just be good enough to examine the end result and check that
>>it is good. At least while you test different configurations.
> 
> 
> Right.  And ultimately, I think we'll want the hierarchy I mentioned in the 
> comments, that'll cover us a little better I think.
> 

Yeah I would agree. No doubt you could spend a long time on improving
it. Start simple so you have a baseline of course.

If you're going to be looking at this, take a look at the way we're
building domains in the "[PATCH] consolidate sched domains" patch I
posted the other day. It may simplify your job as well, for example if
you can make use of the init_sched_build_groups function.


      reply	other threads:[~2004-07-25  4:26 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-07-22 16:41 [RFC] Patch for isolated scheduler domains Dimitri Sivanich
2004-07-22 16:41 ` Dimitri Sivanich
2004-07-22 17:54 ` Ingo Molnar
2004-07-22 17:54   ` Ingo Molnar
2004-07-23  3:27   ` Nick Piggin
2004-07-23  3:27     ` Nick Piggin
2004-07-23  4:13     ` Dimitri Sivanich
2004-07-23  4:13       ` Dimitri Sivanich
2004-07-23  4:29       ` Nick Piggin
2004-07-23  4:29         ` Nick Piggin
2004-07-22 19:34 ` Paul Jackson
2004-07-22 19:34   ` Paul Jackson
2004-07-23 20:03 ` Jesse Barnes
2004-07-24  5:26   ` Nick Piggin
2004-07-24 15:40     ` Jesse Barnes
2004-07-25  4:26       ` Nick Piggin [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=41033687.4080304@yahoo.com.au \
    --to=nickpiggin@yahoo.com.au \
    --cc=hawkes@sgi.com \
    --cc=jbarnes@engr.sgi.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sivanich@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 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.