linux-kernel - Re: [patch 07/11] x86/perf/uncore: Track packages not per cpu data

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]

Message-ID: <alpine.DEB.2.11.1602180942100.19512@nanos>
Date:	Thu, 18 Feb 2016 11:22:34 +0100 (CET)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Peter Zijlstra <peterz@...radead.org>
cc:	Andi Kleen <andi@...stfloor.org>,
	Stephane Eranian <eranian@...gle.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...nel.org>, Borislav Petkov <bp@...en8.de>,
	Harish Chegondi <harish.chegondi@...el.com>,
	Kan Liang <kan.liang@...el.com>,
	Andi Kleen <andi.kleen@...el.com>
Subject: Re: [patch 07/11] x86/perf/uncore: Track packages not per cpu data

On Thu, 18 Feb 2016, Peter Zijlstra wrote:
> On Wed, Feb 17, 2016 at 11:16:40PM +0100, Andi Kleen wrote:
> > > Do you have any data to back that up or is that just "believe" ?
> > 
> > I've seen systems with discontiguous apic ids before.
> > 
> > It is obvious if you consider setups with node hotplug.
> 
> Those systems will also have a num_possible_cpus() that's inflated to
> account for the possible hotplug of new sockets, right?
> 
> So while the phys_pkg_id of the present sockets might be 2 and 3
> (leaving 0 and 1 available for hotplug), the num_possible_cpus() should
> be big enough to actually allow for that hotplug to happen.
> 
> Because if num_possible_cpus() is too small, we could not accommodate
> the hotplug operation.
> 
> And if num_possible_cpus() is of the right size, then the computed
> max_packages() should be of the right size too.
> 
> Now clearly, BIOS can completely wreck things and indeed report too
> small an apic_id range or whatever, and in this case we're up a creek
> without a paddle.
> 
> But I think you can check for that at boot and report errors/warns
> whatever, because if you trigger this, your system is not really
> 'correct' anyway.

Correct. Furthermore, we have a limitation of apic ids anyway. So there is a
limitation of creative apic id assignements already.

Now if the system implementer can assign apic ids randomly in that space, the
assumption of 

	   maxpackages = num_possible_cpus / cpus_per_package

is not longer true. But that's not a blocker for the approach of tracking per
package data. We simply can create logical package ids and use those.

So there is another possible issue. The above is also not true if we get
heterogenous systems, i.e. cpus_per_package is non constant. But if we create
logical package ids when building the system topoplogy the we can account for
that and adjust maxpackages accordingly.

Thanks,

	tglx