Re: [patch 0/5] x86_64 CPU hotplug patch series.

[Andi Kleen <ak@muc.de>]

Zwane Mwaikambo <zwane@arm.linux.org.uk> writes:

> On Thu, 2 Jun 2005, Ashok Raj wrote:
>
>> Andrew: Could you help test staging in -mm so we can get some wider testing
>> from those interested.
>> 
>> *Sore Point*: Andi doesnt agree with one patch that removes ipi-broadcast 
>> and uses only online map cpus receive IPI's. This is much simpler approach to 
>> handle instead of trying to remove the ill effects of IPI broadcast to CPUs in 
>> offline state.
>> 
>> Initial concern from Andi was IPI performance, but some primitive test with a 
>> good number of samples doesnt seem to indicate any degration at all, infact the
>> results seem identical. (Barring any operator errors :-( ).
>> 
>> It would be nice to hear other opinions as well, hopefuly we can close on
>> what what the right approach in this case. Link to an earlier discussion
>> on the topic.
>
> I don't think it's worth the extra boot time complexity to use the boot 
> workaround and i'm not convinced the extra mask against cpu_online_map 
> slows down that path enough to show up compared to waiting for remote 
> processor IPI handling to commence/complete.

What boot slowdown? 

I assume any practical CPU hotplug will have a way to detect it 
at boot - e.g. ACPI will probably need to tell you about spare
CPUs that could be started or there is a command line option.

My request was basically to set a flag when "CPU hotplug possible"
is detected and then only use the slow fast path method when
CPU hotplug is possible.

Actually that was only the second best solution, better would
be to just fix the relatively obscure race in the CPU hotplug bootup
path, but Ashok for some reason seems to be very adverse to that
option.

-Andi