public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Matthew Dobson <colpatch@us.ibm.com>
To: Paul Jackson <pj@sgi.com>
Cc: nickpiggin@yahoo.com.au, dino@in.ibm.com, Simon.Derr@bull.net,
	linux-kernel@vger.kernel.org, lse-tech@lists.sourceforge.net,
	akpm@osdl.org, dipankar@in.ibm.com
Subject: Re: [RFC PATCH] Dynamic sched domains aka Isolated cpusets
Date: Mon, 25 Apr 2005 17:52:29 -0700	[thread overview]
Message-ID: <426D90CD.3090207@us.ibm.com> (raw)
In-Reply-To: <20050423162640.69ccbabc.pj@sgi.com>

Paul Jackson wrote:
> A few days ago, Nick wrote:
> 
>>Well the scheduler simply can't handle it, so it is not so much a
>>matter of pushing - you simply can't use partitioned domains and
>>meaningfully have a cpuset above them.
> 
> 
> And I (pj) replied:
> 
>>Translating that into cpuset-speak, I think what you mean is ...
> 
> 
> I then went on to ask some questions.  I haven't seen a reply.
> I probably wrote too many words, and you had more pressing matters
> to deal with.  Which is fine.
> 
> Let's make this simpler.
> 
> Ignore cpusets -- let's just talk about a tasks cpus_allowed value,
> and scheduler domains.  Think of cpusets as just a strange way of
> setting a tasks cpus_allowed value.
> 
> Question:
> 
>     What happens if we have say two isolated scheduler domains
>     on a system, covering say two halves of the system, and
>     some task has its cpus_allowed set to allow _all_ CPUs?
> 
> What kind of pain does that cause?  I'm hoping you will say that
> the only pain it causes is that the task will only run on one
> half of the system, even if the other half is idle.  And that
> so long as I don't mind that, it's no problem to do this.

I'm not the sched_domains guru that Nick is, but as your question has gone
unanswered for a few days I'll chime in and see if I can't help you provoke
a more definitive response.

Your assumptions above are correct to the best of my knowledge.  The only
pain it causes is that the scheduler will not be able to "see" outside of
the span of the highest sched_domain attached to a particular CPU.


        A          B
       / \        / \
      X   Y      Z   W
     /\   /\    /\   /\
    0  1 2  3  4  5 6  7

In this setup, with your "Alpha" & "Beta" domains splitting the system in
half, a process in a cpuset spanning cpus 0..7 will get "stuck" in
whichever domain it happens to be in when the Alpha & Beta domains get
created.  Explicit sys_sched_setaffinity() calls will still move it between
domains, but it will not move between Alpha & Beta on its own.
Loadbalancing from CPU 0's perspective (in Alpha) sees only CPUs 0..3.

Right Nick? ;)

-Matt

  reply	other threads:[~2005-04-26  0:52 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 [this message]
2005-04-26  0:59                 ` Paul Jackson
2005-04-19  9:52       ` Dinakar Guniguntala
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=426D90CD.3090207@us.ibm.com \
    --to=colpatch@us.ibm.com \
    --cc=Simon.Derr@bull.net \
    --cc=akpm@osdl.org \
    --cc=dino@in.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