public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "John Hawkes" <hawkes@sgi.com>
To: <dino@in.ibm.com>, "Paul Jackson" <pj@sgi.com>
Cc: <paulus@samba.org>, "Andrew Morton" <akpm@osdl.org>,
	<nickpiggin@yahoo.com.au>, <linux-ia64@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>, <torvalds@osdl.org>,
	<mingo@elte.hu>
Subject: Re: [PATCH 2.6.13-rc6] cpu_exclusive sched domains build fix
Date: Wed, 24 Aug 2005 09:09:40 -0700	[thread overview]
Message-ID: <006a01c5a8c6$3c2006d0$6600a8c0@PCJohn> (raw)
In-Reply-To: 20050824112640.GB5197@in.ibm.com

From: "Dinakar Guniguntala" <dino@in.ibm.com>
> Can we hold on to this patch for a while, as I reported yesterday,
> this hangs up my ppc64 box on doing rmdir on a exclusive cpuset.
> Still debugging the problem, hope to have a fix soon, Thanks

Paul's patch simply constrains the scope of cpuset configurations that will 
invoke the "dynamic sched domains" functionality, which means that some 
cpu-exclusive (a.k.a. "isolated") cpusets will continue to have the 
2.6.12-and-earlier behavior of being periodically examined by the CPU 
Scheduler in load-balancing activities.  That is, Paul's patch simply reverts 
cpuset/sched domain behavior to pre-2.6.13 status (for some cpusets).

The pre-2.6.13 non-"dynamic sched domains" behavior will in fact produce bad 
load-balancing behavior if a cpu-exclusive cpuset is so heavily loaded with 
executing processes, all pinned to the cpu(s) in the cpuset, that the other 
cpus in the system see this cpu(s)/node as the most-heavily-loaded and just 
focus on it during load-balancing -- which would be futile, of course, since 
the processes pinned to this highest-load cpu (and node) cannot be offloaded. 
Since load-balancing looks only at the most-heavily-loaded cpu as a cpu to 
offload, this means that all system load-balancing would be effectively turned 
off.

John Hawkes 


      parent reply	other threads:[~2005-08-24 16:10 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-08-24 11:15 [PATCH 2.6.13-rc6] cpu_exclusive sched domains build fix Paul Jackson
2005-08-24 11:26 ` Dinakar Guniguntala
2005-08-24 11:46   ` Paul Jackson
2005-08-24 12:01     ` Nick Piggin
2005-08-24 20:31       ` Paul Jackson
2005-08-25  0:02         ` Nick Piggin
2005-08-25  0:57           ` Paul Jackson
2005-08-25 14:41         ` Dinakar Guniguntala
2005-08-25 15:20           ` Paul Jackson
2005-08-24 16:09   ` John Hawkes [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='006a01c5a8c6$3c2006d0$6600a8c0@PCJohn' \
    --to=hawkes@sgi.com \
    --cc=akpm@osdl.org \
    --cc=dino@in.ibm.com \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=nickpiggin@yahoo.com.au \
    --cc=paulus@samba.org \
    --cc=pj@sgi.com \
    --cc=torvalds@osdl.org \
    /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