public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Mike Galbraith <efault@gmx.de>
To: Nick Piggin <npiggin@suse.de>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Ingo Molnar <mingo@elte.hu>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>
Subject: Re: newidle balancing in NUMA domain?
Date: Mon, 23 Nov 2009 15:37:39 +0100	[thread overview]
Message-ID: <1258987059.6193.73.camel@marge.simson.net> (raw)
In-Reply-To: <20091123112228.GA2287@wotan.suse.de>

On Mon, 2009-11-23 at 12:22 +0100, Nick Piggin wrote:
> Hi,
> 
> I wonder why it was decided to do newidle balancing in the NUMA
> domain? And with newidle_idx == 0 at that.
> 
> This means that every time the CPU goes idle, every CPU in the
> system gets a remote cacheline or two hit. Not very nice O(n^2)
> behaviour on the interconnect. Not to mention trashing our
> NUMA locality.

Painful on little boxen too if left unchained.
 
> And then I see some proposal to do ratelimiting of newidle
> balancing :( Seems like hack upon hack making behaviour much more
> complex.

That's mine, and yeah, it is hackish.  It just keeps newidle at bay for
high speed switchers while keeping it available to kick start CPUs for
fork/exec loads.  Suggestions welcome.  I have a threaded testcase
(x264) where turning the think off costs ~40% throughput.  Take that
same testcase (or ilk) to a big NUMA beast, and performance will very
likely suck just as bad as it does on my little Q6600 box.

Other than that, I'd be most happy to see the thing crawl back in it's
cave and _die_ despite the little gain it provides for a kbuild.  It has
been (is) very annoying.

> One "symptom" of bad mutex contention can be that increasing the
> balancing rate can help a bit to reduce idle time (because it
> can get the woken thread which is holding a semaphore to run ASAP
> after we run out of runnable tasks in the system due to them 
> hitting contention on that semaphore).

Yes, when mysql+oltp starts jamming up, load balancing helps bust up the
logjam somewhat, but that's not at all why newidle was activated..

> I really hope this change wasn't done in order to help -rt or
> something sad like sysbench on MySQL.

Newidle was activated to improve fork/exec CPU utilization.  A nasty
side effect is that it tries to rip other loads to tatters.

> And btw, I'll stay out of mentioning anything about CFS development,
> but it really sucks to be continually making significant changes to
> domains balancing *and* per-runqueue scheduling at the same time :(
> It makes it even difficult to bisect things.

Yeah, balancing got jumbled up with desktop tweakage.  Much fallout this
round, and some things still to be fixed back up.

	-Mike


  parent reply	other threads:[~2009-11-23 14:37 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-23 11:22 newidle balancing in NUMA domain? Nick Piggin
2009-11-23 11:36 ` Peter Zijlstra
2009-11-23 11:43   ` Nick Piggin
2009-11-23 11:50     ` Peter Zijlstra
2009-11-23 12:16       ` Nick Piggin
2009-11-23 11:45   ` Ingo Molnar
2009-11-23 12:01     ` Nick Piggin
2009-11-23 12:08       ` Ingo Molnar
2009-11-23 12:27         ` Nick Piggin
2009-11-23 12:46           ` Ingo Molnar
2009-11-24  6:36             ` Nick Piggin
2009-11-24 17:24               ` Jason Garrett-Glaser
2009-11-24 18:09                 ` Mike Galbraith
2009-11-30  8:19                 ` Nick Piggin
2009-12-01  8:18                   ` Jason Garrett-Glaser
2009-11-23 14:37 ` Mike Galbraith [this message]
2009-11-23 15:11   ` Nick Piggin
2009-11-23 15:21     ` Peter Zijlstra
2009-11-23 15:29       ` Nick Piggin
2009-11-23 15:37         ` Peter Zijlstra
2009-11-24  6:54           ` Nick Piggin
2009-11-23 15:53         ` Mike Galbraith
2009-11-24  6:53           ` Nick Piggin
2009-11-24  8:40             ` Mike Galbraith
2009-11-24  8:58               ` Mike Galbraith
2009-11-24  9:11                 ` Ingo Molnar
2009-11-30  8:27                   ` Nick Piggin
2009-11-23 17:04         ` Ingo Molnar
2009-11-24  6:59           ` Nick Piggin
2009-11-24  9:16             ` Ingo Molnar

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=1258987059.6193.73.camel@marge.simson.net \
    --to=efault@gmx.de \
    --cc=a.p.zijlstra@chello.nl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=npiggin@suse.de \
    /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