linux-kernel - Re: [PATCH 2/2] s390/topology: add drawer scheduling domain level

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 13 Jun 2016 13:22:30 +0200
From:	Heiko Carstens <heiko.carstens@...ibm.com>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Martin Schwidefsky <schwidefsky@...ibm.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] s390/topology: add drawer scheduling domain level

On Mon, Jun 13, 2016 at 01:06:21PM +0200, Peter Zijlstra wrote:
> 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@...radead.org>

Thanks!

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

Yes, and actually we are all virt/LPAR always, so this is unfortunately not
very easy to do. And yes, I do agree that for the 1:1 case it most likely
would make sense, however we don't have any run-time guarantee to stay 1:1.

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

That's something we need to look into further as well. Thanks for pointing
this out!