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

Powered by blists - more mailing lists