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
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
