On Sun, 26 Jan 2014, Ingo Molnar wrote:
> > > So the problem is that the counting of disabled but hotpluggable
> > > CPUs is over-eager.
> >
> > In the kernel, yeah, and we don't distinguish between physically
> > absent processors that have lapic entries and physically present but
> > disabled processors.
>
> Correct. Is there a robust distinction possible between the two?
>
Not with acpi, I'm afraid, which allows for both possibilities to either
have no lapic entry or have ACPI_MADT_ENABLED clear.
> > > --- a/arch/x86/kernel/smpboot.c
> > > +++ b/arch/x86/kernel/smpboot.c
> > > @@ -1223,10 +1223,7 @@ __init void prefill_possible_map(void)
> > > i = setup_max_cpus ?: 1;
> > > if (setup_possible_cpus == -1) {
> > > possible = num_processors;
> > > -#ifdef CONFIG_HOTPLUG_CPU
> > > - if (setup_max_cpus)
> > > - possible += disabled_cpus;
> > > -#else
> > > +#ifndef CONFIG_HOTPLUG_CPU
> > > if (possible > i)
> > > possible = i;
> > > #endif
> >
> > Yeah, this should suppress the warning for Dave. This way, the only way
> > the log reports the number of "hotplug CPUs" is because we used
> > possible_cpus.
>
> Not just that, it also reduces the number of possible CPUs, which
> should reduce percpu memory allocation overhead, amongst other things,
> right?
>
Indeed, it gives people a good motivation for clearing out those
unnecessary lapic entries :)
> I wouldn't object to someone sending a changelogged, tested patch that
> does all that. Maybe two patches: first the cleanups, then the CPU
> count trimming. Just in case it regresses ...
>
Sounds good. I need to look into your point about kexec as far as the
possible count trimming first for the second patch.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
