Re: [RFC PATCH v2] ACPI / processor: Fix possible CPUs map

[Dou Liyang <douly.fnst@cn.fujitsu.com>]

Hi Thomas,

At 03/15/2018 09:45 PM, Thomas Gleixner wrote:
[...]

> I tested this on a machine which claims to have gazillion of hotplugable
> CPUs:

I really appreciate your test.

> 
> 	smpboot: Allowing 152 CPUs, 120 hotplug CPUs
> 	setup_percpu: NR_CPUS:512 nr_cpumask_bits:512 nr_cpu_ids:152 nr_node_ids:2
> 	smp: Brought up 2 nodes, 32 CPUs
> 
> Now with your patch applied it's still saying:
> 
> 	smpboot: Allowing 152 CPUs, 120 hotplug CPUs
> 	setup_percpu: NR_CPUS:512 nr_cpumask_bits:512 nr_cpu_ids:152 nr_node_ids:2
> 	smp: Brought up 2 nodes, 32 CPUs
> 
> and the above code runs later on and the result is:
> 
> 	nr_unique_ids 1 nr_cpu_ids 152
> 	Allowing 1 possible CPU
> 
> which subsequently causes the machine to die as we have already 32 CPUs
> online.
> 

That is so interesting, it proofs that this strategy is risky.

I've been wondering how to determine the number of possible CPUs. Due to
the diversity of ACPI in different systems, that seems impossible. Why 
don't I change my mind? Here is a new strategy and I think it is more
reasonable and minimally invasive.

   As we all know, we reset possible CPUs in the prefill_possible_map(),
   If CONFIG_HOTPLUG_CPU = y :
       nr_possible_CPUs = num_processors + disabled_cpus.

   Before the prefill_possible_map(), *Fix the inaccurate disabled_cpus*:

     1) For each disabled CPUs, get it's processor id from ACPI MADT

     2) Check whether this processor id is existed in ACPI namespace or not.
        If false, disabled_cpus--;

I will show you the code and test it later. And IMO, the code logic in
prefill_possible_map() is a little mess, will try to sort it out first.

> So nr_unique_ids is not what it should be and even if it would be the code
> runs way too late. It needs to run _before_ setup_percpu() is invoked to
> scale everything correctly.
> 

Yes, Got it.

Thanks,
	dou

> Thanks,
> 
> 	tglx
> 
> 
> 
> 
> 
>