From: Rik van Riel <riel@redhat.com>
To: Peter Zijlstra <peterz@infradead.org>,
Brendan Gregg <brendan.d.gregg@gmail.com>
Cc: Jeff Merkey <linux.mdb@gmail.com>,
LKML <linux-kernel@vger.kernel.org>,
Mike Galbraith <umgwanakikbuti@gmail.com>,
Ingo Molnar <mingo@kernel.org>
Subject: Re: [RFC] The Linux Scheduler: a Decade of Wasted Cores Report
Date: Mon, 25 Apr 2016 13:54:08 -0400 [thread overview]
Message-ID: <1461606848.13397.42.camel@redhat.com> (raw)
In-Reply-To: <20160425093424.GE12845@twins.programming.kicks-ass.net>
[-- Attachment #1: Type: text/plain, Size: 1349 bytes --]
On Mon, 2016-04-25 at 11:34 +0200, Peter Zijlstra wrote:
> On Sat, Apr 23, 2016 at 06:38:25PM -0700, Brendan Gregg wrote:
> >
> > Their proof of concept patches are online[1]. I tested them and saw
> > 0%
> > improvements on the systems I tested, for some simple workloads[2].
> > I
> > tested 1 and 2 node NUMA, as that is typical for my employer
> > (Netflix,
> > and our tens of thousands of Linux instances in the AWS/EC2 cloud),
> > even though I wasn't expecting any difference on 1 node. I've used
> > synthetic workloads so far.
> So their setup uses a bigger (not fully connected) NUMA topology, and
> I'm not entirely sure how much of their problems are due to that, but
> at
> least one of them is.
>
> Such boxes are fairly rare.
Their proposed fix, of making sure we build all 8 sched
groups with 5 nodes each in them seems a little bit
roundabout when compared with a simpler alternative,
though.
When dealing with a NUMA_GLUELESS_MESH topology, we
should simply not build any sched domains with multiple
nodes inside them, except for the top level domain that
contains all the nodes.
At that point, we will balance between threads, inside
each core, and between all nodes, without running into
those pointless (and potentially harmful) intermediate
sched domains.
--
All Rights Reversed.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
prev parent reply other threads:[~2016-04-25 17:54 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-23 18:20 [RFC] The Linux Scheduler: a Decade of Wasted Cores Report Jeff Merkey
2016-04-24 1:38 ` Brendan Gregg
2016-04-24 7:05 ` Mike Galbraith
2016-04-25 9:18 ` Mike Galbraith
2016-04-27 7:09 ` [patch] sched: Fix smp nice induced group scheduling load distribution woes Mike Galbraith
2016-04-28 9:11 ` Peter Zijlstra
2016-04-28 12:29 ` Mike Galbraith
2016-04-25 9:34 ` [RFC] The Linux Scheduler: a Decade of Wasted Cores Report Peter Zijlstra
2016-04-25 17:54 ` Rik van Riel [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=1461606848.13397.42.camel@redhat.com \
--to=riel@redhat.com \
--cc=brendan.d.gregg@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux.mdb@gmail.com \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=umgwanakikbuti@gmail.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