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