All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nick Piggin <npiggin@suse.de>
To: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Ingo Molnar <mingo@elte.hu>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>
Subject: newidle balancing in NUMA domain?
Date: Mon, 23 Nov 2009 12:22:28 +0100	[thread overview]
Message-ID: <20091123112228.GA2287@wotan.suse.de> (raw)

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.

And then I see some proposal to do ratelimiting of newidle
balancing :( Seems like hack upon hack making behaviour much more
complex.

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).

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

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.

Thanks,
Nick


             reply	other threads:[~2009-11-23 11:22 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-23 11:22 Nick Piggin [this message]
2009-11-23 11:36 ` newidle balancing in NUMA domain? 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
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=20091123112228.GA2287@wotan.suse.de \
    --to=npiggin@suse.de \
    --cc=a.p.zijlstra@chello.nl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    /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.