All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Ken Chen <kenchen@google.com>
Cc: Nick Piggin <nickpiggin@yahoo.com.au>,
	"Siddha, Suresh B" <suresh.b.siddha@intel.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [patch] sched: fix improper load balance across sched domain
Date: Wed, 17 Oct 2007 09:20:03 +0200	[thread overview]
Message-ID: <20071017072003.GA18044@elte.hu> (raw)
In-Reply-To: <b040c32a0710161207s4d6d4d4cq1fa7f0dd1a7f017d@mail.gmail.com>


* Ken Chen <kenchen@google.com> wrote:

> We recently discovered a nasty performance bug in the kernel CPU load 
> balancer where we were hit by 50% performance regression.
> 
> When tasks are assigned to a subset of CPUs that span across 
> sched_domains (either ccNUMA node or the new multi-core domain) via 
> cpu affinity, kernel fails to perform proper load balance at these 
> domains, due to several logic in find_busiest_group() miss identified 
> busiest sched group within a given domain. This leads to inadequate 
> load balance and causes 50% performance hit.
[...]
> So proposing the following fix: add addition logic in 
> find_busiest_group to detect intrinsic imbalance within the busiest 
> group.  When such condition is detected, load balance goes into spread 
> mode instead of default grouping mode.

thanks - i've added your fix to the scheduler queue, and i'll check it 
with a few workloads too. (Right now the scheduler queue is blocked by a 
showstopper crasher bug in group scheduling and we are trying to fix 
that first, before doing any other change.)

	Ingo

      parent reply	other threads:[~2007-10-17  7:20 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-16 19:07 [patch] sched: fix improper load balance across sched domain Ken Chen
2007-10-17  2:23 ` Siddha, Suresh B
2007-10-17 17:08   ` Ken Chen
2007-10-17  7:20 ` Ingo Molnar [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=20071017072003.GA18044@elte.hu \
    --to=mingo@elte.hu \
    --cc=akpm@linux-foundation.org \
    --cc=kenchen@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nickpiggin@yahoo.com.au \
    --cc=suresh.b.siddha@intel.com \
    --cc=torvalds@linux-foundation.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 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.