public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Paul Jackson <pj@sgi.com>
Cc: holt@sgi.com, suresh.b.siddha@intel.com, dino@in.ibm.com,
	menage@google.com, Simon.Derr@bull.net,
	linux-kernel@vger.kernel.org, mbligh@google.com,
	rohitseth@google.com, dipankar@in.ibm.com
Subject: Re: exclusive cpusets broken with cpu hotplug
Date: Thu, 19 Oct 2006 17:04:42 +1000	[thread overview]
Message-ID: <4537238A.7060106@yahoo.com.au> (raw)
In-Reply-To: <20061018235746.95343e77.pj@sgi.com>

Paul Jackson wrote:
> Nick wrote:
> 
>>I don't understand why you think the "implicit" (as in, not directly user
>>controlled?) linkage is wrong.
> 
> 
> Twice now I've given the following specific example.  I am not yet
> confident that I have it right, and welcome feedback.

Sorry, I skimmed over that.

> 
> However, Suresh has apparently agreed with my conclusion that one
> can use the current linkage between cpu_exclusive cpusets and sched
> domains to get unexpected and perhaps undesirable sched domain setups.
> 
> What's your take on this example:
> 
> 
>>Example:
>>
>>    As best as I can tell (which is not very far ;), if some hapless
>>    user does the following:
>>
>>	    /dev/cpuset		cpu_exclusive == 1; cpus == 0-7
>>	    /dev/cpuset/a	cpu_exclusive == 1; cpus == 0-3
>>	    /dev/cpsuet/b	cpu_exclusive == 1; cpus == 4-7
>>
>>    and then runs a big job in the top cpuset (/dev/cpuset), then that
>>    big job will not load balance correctly, with whatever threads
>>    in the big job that got stuck on cpus 0-3 isolated from whatever
>>    threads got stuck on cpus 4-7.
>>
>>Is this correct?
> 
> 
> If I have concluded incorrectly what happens in the above example
> (good chance) then please educate me on how this stuff works.

So that depends on what cpusets asks for. If, when setting up a and
b, it asks to partition the domains, then yes that breaks the parent
cpuset gets broken.

> I should warn you that I have demonstrated a remarkable resistance
> to being educatible on this subject ;).

Don't worry about the whole sched-domains implementation if you just
consider that partitioning the domains creates a hard partition
among the system's CPUs (but the upshot is that within the partitions,
balancing works pretty nicely).

So in your above example, cpusets should only ask for a partition of
the 0-7 CPUs.

If you wanted to get fancy and detect that there are no jobs in the
root cpuset, then you could make the two smaller partitions, and revert
back to the one bigger one if something gets assigned to it.

But that's all a matter of how you want cpusets to manage it, I really
don't think a user should control this (we simply shouldn't allow
situations where we put a partition in the middle of a cpuset).

Thanks,
Nick

-- 
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com 

  reply	other threads:[~2006-10-19  7:04 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-18  2:25 exclusive cpusets broken with cpu hotplug Siddha, Suresh B
2006-10-18  7:14 ` Paul Jackson
2006-10-18  9:56   ` Robin Holt
2006-10-18 10:10     ` Paul Jackson
2006-10-18 10:53       ` Robin Holt
2006-10-18 21:07         ` Paul Jackson
2006-10-19  5:56           ` Paul Jackson
2006-10-18 12:16       ` Nick Piggin
2006-10-18 14:14         ` Siddha, Suresh B
2006-10-18 14:51           ` Nick Piggin
2006-10-19  6:15         ` Paul Jackson
2006-10-19  6:35           ` Nick Piggin
2006-10-19  6:57             ` Paul Jackson
2006-10-19  7:04               ` Nick Piggin [this message]
2006-10-19  7:33                 ` Paul Jackson
2006-10-19  8:16                   ` Nick Piggin
2006-10-19  8:31                     ` Paul Jackson
2006-10-19  7:34                 ` Paul Jackson
2006-10-19  8:07                   ` Nick Piggin
2006-10-19  8:11                     ` Paul Jackson
2006-10-19  8:22                       ` Nick Piggin
2006-10-19  8:42                         ` Paul Jackson
2006-10-18 17:54 ` Dinakar Guniguntala
2006-10-18 18:05   ` 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=4537238A.7060106@yahoo.com.au \
    --to=nickpiggin@yahoo.com.au \
    --cc=Simon.Derr@bull.net \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox