public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Peter Williams <pwil3058@bigpond.net.au>
To: "Siddha, Suresh B" <suresh.b.siddha@intel.com>
Cc: Andrew Morton <akpm@osdl.org>, Mike Galbraith <efault@gmx.de>,
	Nick Piggin <nickpiggin@yahoo.com.au>,
	Ingo Molnar <mingo@elte.hu>,
	"Chen, Kenneth W" <kenneth.w.chen@intel.com>,
	Con Kolivas <kernel@kolivas.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] sched: prevent high load weight tasks suppressing balancing
Date: Tue, 28 Mar 2006 10:21:38 +1100	[thread overview]
Message-ID: <44287382.4050108@bigpond.net.au> (raw)
In-Reply-To: <20060327135204.B12364@unix-os.sc.intel.com>

Siddha, Suresh B wrote:
> This breaks HT and MC optimizations.. Consider a DP system with each
> physical processor having two HT logical threads.. if there are two 
> runnable processes running on package-0, with this patch scheduler 
> will never move one of those processes to package-1..

Is this an active_load_balance() issue?

If it is then I suggest that the solution is to fix the 
active_load_balance() and associated code so that it works with this 
patch in place.

It would be possible to modify find_busiest_group() and 
find_busiest_queue() so that they just PREFER the busiest group to have 
at least one CPU with more than one running task and the busiest queue 
to have more than one task.  However, this would make the code 
considerably more complex and I'm reluctant to impose that on all 
architectures just to satisfy HT and MC requirements.  Are there 
configuration macros or other means that I can use to exclude this 
(proposed) code on systems where it isn't needed i.e. non HT and MC 
systems or HT and MC systems with only one package.

Personally, I think that the optimal performance of the load balancing 
code has already been considerably compromised by its unconditionally 
accommodating the requirements of active_load_balance() (which you have 
said is now only required by HT and MC systems) and that it might be 
better if active load balancing was separated out into a separate 
mechanism that could be excluded from the build on architectures that 
don't need it.  I can't help thinking that this would result in a more 
efficient active load balancing mechanism as well because the current 
one is very inefficient.

Peter
PS I don't think that this issue is sufficiently important to prevent 
the adoption of the smpnice patches while it's being resolved.
-- 
Peter Williams                                   pwil3058@bigpond.net.au

"Learning, n. The kind of ignorance distinguishing the studious."
  -- Ambrose Bierce

  reply	other threads:[~2006-03-27 23:21 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <4427873A.4010601@bigpond.net.au>
2006-03-27 21:52 ` [PATCH] sched: prevent high load weight tasks suppressing balancing Siddha, Suresh B
2006-03-27 23:21   ` Peter Williams [this message]
2006-03-28  3:15     ` Siddha, Suresh B
2006-03-28  4:17       ` Peter Williams

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=44287382.4050108@bigpond.net.au \
    --to=pwil3058@bigpond.net.au \
    --cc=akpm@osdl.org \
    --cc=efault@gmx.de \
    --cc=kenneth.w.chen@intel.com \
    --cc=kernel@kolivas.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=nickpiggin@yahoo.com.au \
    --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