Re: <PING> Re: [patch x86/core] x86: allow number of additional hotplug CPUs to be set at compile time

[Andi Kleen <andi@firstfloor.org>]

> 
>> Btw, additional_cpus has interesting properties. Providing a negative 
>> number < -1 on the kernel command line - happened due to a typo - 
>> explodes in early boot, which is not really surprising, but should be 
>> sanity checked.
> 
> indeed, and that mess was introduced, interestingly, by this commit, 
> three years ago, by Andi:

What mess do you mean? That not all parameters are 100% sanity checked?
"Unix gives you enough rope to shot yourself into the foot."
Normally people who set kernel parameters are expected to know what
they are doing. That said the parameter should probably use some
unsigned form of get_option, but unfortunately there isn't any.

But if you describe any kernel parameter that isn't 100% sanity
checked as mess I'm afraid there won't be many non messy parameters
left.

> | From 420f8f68c9c5148dddf946bebdbc7eacde2172cb Mon Sep 17 00:00:00 2001
> | From: Andi Kleen <ak@suse.de>
> | Date: Sat, 5 Nov 2005 17:25:54 +0100
> | Subject: [PATCH] [PATCH] x86_64: New heuristics to find out hotpluggable CPUs.
> 
> so to clean up the mess i've removed the additional_cpus= boot parameter 
> and the Kconfig entry as well - see the patch in x86/core below.

This also breaks real CPU hotplug on systems that do not follow
the Documentation/x86/x86_64/cpu-hotplug-spec specification.

This extension is not part of the standard ACPI spec (I invented it),
so I don't think everyone requiring to follow such a Linux specific extension
is a good idea. I tried to lobby a few vendors to follow this
extension, but I doubt I was 100% successfull.

So please readd the boot parameter.

Or if you don't chose it at least modify the document clearly
stating that all CPU hotplug requires a non ACPI standard extension now
and that the users is screwed if their vendor doesn't follow it.

But it would be better to keep the parameter as a fallback.

> and no way can any of this go into v2.6.27: this is fragile code with a 
> lot of historic baggage

In my experience CPU discovery in ACPI/mptables isn't particularly fragile.
alternatives can be, but this patch doesn't affect its basic operation.

> and the original error is non-fatal to begin 
> with. 

That is true, it's just a performance issue especially on systems
with slow LOCK prefix (like P4s) which commonly have the bogus extra
CPU in the BIOS tables when they don't support HT directly.

-Andi