From: Peter Zijlstra <peterz@infradead.org>
To: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Martin Schwidefsky <schwidefsky@de.ibm.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] s390/topology: add drawer scheduling domain level
Date: Mon, 13 Jun 2016 13:06:21 +0200 [thread overview]
Message-ID: <20160613110621.GV30909@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <1465376956-100711-3-git-send-email-heiko.carstens@de.ibm.com>
On Wed, Jun 08, 2016 at 11:09:16AM +0200, Heiko Carstens wrote:
> The z13 machine added a fourth level to the cpu topology
> information. The new top level is called drawer.
>
> A drawer contains two books, which used to be the top level.
>
> Adding this additional scheduling domain did show performance
> improvements for some workloads of up to 8%, while there don't
> seem to be any workloads impacted in a negative way.
Right; so no objection.
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
You still don't want to make NUMA explicit on this thing? So while I
suppose the SC 480M L4 cache does hide some of it, there can be up to 8
nodes on this thing. Which seems to me there's win to be had by exposing
it.
Of course, the moment you go all virt/LPAR on it, that all gets really
interesting, but for those cases where you run 1:1 it might make sense.
Also, are you sure you don't want some of the behaviour changed for the
drawer domains? I could for example imagine you wouldn't want
SD_WAKE_AFFINE set (we disable that for NUMA domains as well).
next prev parent reply other threads:[~2016-06-13 11:06 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-08 9:09 [PATCH 0/2] s390: introduce drawer scheduling domain Heiko Carstens
2016-06-08 9:09 ` [PATCH 1/2] topology/sysfs: provide drawer id and siblings attributes Heiko Carstens
2016-06-08 9:09 ` [PATCH 2/2] s390/topology: add drawer scheduling domain level Heiko Carstens
2016-06-13 11:06 ` Peter Zijlstra [this message]
2016-06-13 11:22 ` Heiko Carstens
2016-06-13 13:06 ` Peter Zijlstra
2016-06-13 13:19 ` Martin Schwidefsky
2016-06-13 13:53 ` Peter Zijlstra
2016-06-13 14:37 ` Martin Schwidefsky
2016-06-13 11:25 ` Heiko Carstens
2016-06-13 11:33 ` Peter Zijlstra
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=20160613110621.GV30909@twins.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=gregkh@linuxfoundation.org \
--cc=heiko.carstens@de.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=schwidefsky@de.ibm.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 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.