linux-kernel - Re: Odd performance results

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 for Android: free password hash cracker in your pocket

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

Date:	Wed, 13 Jul 2016 14:33:37 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Henrique de Moraes Holschuh <hmh@....eng.br>
Cc:	Ingo Molnar <mingo@...nel.org>, "H. Peter Anvin" <hpa@...or.com>,
	paulmck@...ux.vnet.ibm.com, tglx@...utronix.de, mingo@...e.hu,
	ak@...ux.intel.com, linux-kernel@...r.kernel.org
Subject: Re: Odd performance results

On Wed, Jul 13, 2016 at 09:27:48AM -0300, Henrique de Moraes Holschuh wrote:
> On Wed, 13 Jul 2016, Ingo Molnar wrote:
> > > The ordering Paul has, namely 0,1 for core0,smt{0,1} is not something
> > > I've ever seen on an Intel part. AMD otoh does enumerate their CMT stuff
> > > like what Paul has.
> > 
> > That's more the natural 'direct' mapping from CPU internal topology to CPU id: 
> > what's close to each other physically is close to each other in the CPU id space 
> > as well.
> 
> But does it correctly reflect the hardware?  That seems to be the real
> question...

Its just enumeration afaict. But its weird that this changed. Some BIOS
team somewhere changed things and I want to know why (and how widespread
this is).