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

From: Ingo Molnar
Date: Sun Oct 05 2008 - 11:20:48 EST



* Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote:

> On Sun, 5 Oct 2008, Ingo Molnar wrote:
> > * Chuck Ebbert <cebbert@xxxxxxxxxx> wrote:
> >
> > > Yes, it works and I don't see how it could cause any problems.
> > >
> > > Ingo, can we get this in 2.6.27? You can drop my original patch.
> > >
> > > Tested-by: Chuck Ebbert <cebbert@xxxxxxxxxx>
> >
> > looks good, applied to tip/x86/core, thanks!
>
> No, this patch is horrible.
>
> The correct check is num_present_cpus(). There is no need to make the
> weird additional_cpus hackery globally available.

ah, indeed!

applied to tip/x86/core and i've zapped Andi's patch.

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

| From 420f8f68c9c5148dddf946bebdbc7eacde2172cb Mon Sep 17 00:00:00 2001
| From: Andi Kleen <ak@xxxxxxx>
| 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.

thanks Thomas for decoding this ...

and no way can any of this go into v2.6.27: this is fragile code with a
lot of historic baggage and the original error is non-fatal to begin
with. It can easily be backported to .27.1 if testing shows that it has
no other adverse side-effects.

Ingo

------------------>