From: Peter Zijlstra <peterz@infradead.org>
To: Steven Sistare <steven.sistare@oracle.com>
Cc: subhra mazumdar <subhra.mazumdar@oracle.com>,
linux-kernel@vger.kernel.org, mingo@redhat.com,
dhaval.giani@oracle.com
Subject: Re: [RESEND RFC PATCH V3] sched: Improve scalability of select_idle_sibling using SMT balance
Date: Mon, 5 Feb 2018 13:48:54 +0100 [thread overview]
Message-ID: <20180205124854.GX2269@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <25d67bd2-cbe7-2c2a-e89a-13a7ca5adc10@oracle.com>
On Fri, Feb 02, 2018 at 04:06:32PM -0500, Steven Sistare wrote:
> On 2/2/2018 2:59 PM, Peter Zijlstra wrote:
> > But then you get that atomic crud to contend on the cluster level, which
> > is even worse than it contending on the core level.
>
> True, but it can still be a net win if we make better scheduling decisions.
> A saving grace is that the atomic counter is only updated if the cpu
> makes a transition from idle to busy or vice versa.
Which can still be a very high rate for some workloads. I always forget
which, but there are plenty workloads that have very frequenct very
short idle times. Mike, do you remember what comes apart when we take
out the sysctl_sched_migration_cost test in idle_balance()?
> We need data for this type of system, showing improvements for normal
> workloads, and showing little downside for a high context switch rate
> torture test.
So core-wide atomics should, on architectures that can do atomics in L1,
be relatively fast. Once you leave L1, atomic contention goes up a fair
bit. And then there's architectures that simply don't do atomics in L1
(like Power).
Testing on my SKL desktop, atomics contending between SMT siblings is
basically free (weirdly enough my test says its cheaper), atomics
contending on the L3 is 10x as expensive, and this is with only 4 cores.
If I test it on my 10 core IVB, I'm up to 20x, and I can't imagine that
getting any better with bigger core count (my IVB does not show SMT
contention as lower, but not particularly more expensive either).
So while I see the point of tracking these numbers (for SMT>2), I don't
think its worth doing outside of the core, and then we still need some
powerpc (or any other architecture with abysmal atomics) tested.
So what we can do is make this counting crud conditional on SMT>2 and
possibly part of the topology flags such that an architecture can
opt-out.
Then select_idle_core can be augmented to remember the least-loaded core
it encounters in its traversal, and go with that.
next prev parent reply other threads:[~2018-02-05 12:49 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-29 23:31 [RESEND RFC PATCH V3] sched: Improve scalability of select_idle_sibling using SMT balance subhra mazumdar
2018-02-01 12:33 ` Peter Zijlstra
2018-02-01 13:33 ` Peter Zijlstra
2018-02-02 16:53 ` Steven Sistare
2018-02-02 17:17 ` Peter Zijlstra
2018-02-02 17:36 ` Steven Sistare
2018-02-02 19:58 ` Peter Zijlstra
2018-02-02 20:51 ` Steven Sistare
2018-02-02 17:37 ` Subhra Mazumdar
2018-02-05 12:19 ` Peter Zijlstra
2018-02-05 22:09 ` Subhra Mazumdar
2018-02-06 9:12 ` Peter Zijlstra
2018-02-07 0:30 ` Subhra Mazumdar
2018-02-07 8:42 ` Peter Zijlstra
2018-02-07 23:10 ` Subhra Mazumdar
2018-02-02 17:21 ` Peter Zijlstra
2018-02-02 17:39 ` Steven Sistare
2018-02-02 18:34 ` Steven Sistare
2018-02-02 20:04 ` Peter Zijlstra
2018-02-02 21:17 ` Steven Sistare
2018-02-03 3:47 ` Mike Galbraith
2018-02-02 19:59 ` Peter Zijlstra
2018-02-02 21:06 ` Steven Sistare
2018-02-05 12:48 ` Peter Zijlstra [this message]
2018-02-05 13:54 ` Mike Galbraith
2018-02-05 17:03 ` Peter Zijlstra
2018-02-05 22:32 ` Subhra Mazumdar
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=20180205124854.GX2269@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=dhaval.giani@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=steven.sistare@oracle.com \
--cc=subhra.mazumdar@oracle.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