Re: [PATCH] x86/smpboot: Make logical package management more robust

[Thomas Gleixner]

On Thu, 8 Dec 2016, Peter Zijlstra wrote:
> On Thu, Dec 08, 2016 at 10:04:25AM +0100, Thomas Gleixner wrote:
> > @@ -289,16 +293,17 @@ int topology_update_package_map(unsigned
> >  	if (test_and_set_bit(pkg, physical_package_map))
> >  		goto found;
> >  
> > -	if (logical_packages_frozen) {
> > -		physical_to_logical_pkg[pkg] = -1;
> > -		pr_warn("APIC(%x) Package %u exceeds logical package max\n",
> > -			apicid, pkg);
> > +	if (logical_packages >= __max_logical_packages) {
> > +		pr_warn("Package %u of CPU %u exceeds BIOS package data %u.\n",
> > +			logical_packages, cpu, __max_logical_packages);
> >  		return -ENOSPC;
> >  	}
> >  
> >  	new = logical_packages++;
> > -	pr_info("APIC(%x) Converting physical %u to logical package %u\n",
> > -		apicid, pkg, new);
> > +	if (new != pkg) {
> > +		pr_info("CPU %u Converting physical %u to logical package %u\n",
> > +			cpu, pkg, new);
> > +	}
> 
> This makes the print conditional on the phy<->logical mapping not
> matching; I thought it was a concious decision to print everything in
> the initial version.
> 
> This way, if we have a 4 node system and nodes 1,2 are crossed we'll
> only see:
> 
>  "Converting physical 2 to logical package 1"
>  "Converting physical 1 to logical package 2"
> 
> And nothing on the other two nodes, which could be slightly confusing.

Fair enough. I make it unconditional again.

> > -	if (logical_packages > __max_logical_packages) {
> > -		pr_warn("Detected more packages (%u), then computed by BIOS data (%u).\n",
> > -			logical_packages, __max_logical_packages);
> > -		logical_packages_frozen = true;
> > -		__max_logical_packages  = logical_packages;
> 
> So we'll never 'shrink' the initially computed max; which could result
> in using more memory than strictly needed, otoh it makes physical
> hotplug happier.

Yes. I was debating that back and forth and at the end decided that making
it simple and robust is a good tradeoff vs. the slightly higher memory
consumption. Though on most systems that's a non issue as number of
possible cpus/packages is the same as the actual available ones. The insane
setups have to suffer - rightfully so.

Thanks,

	tglx