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

[Ashok Raj <ashok.raj@intel.com>]

On Fri, Jun 03, 2005 at 06:35:01PM +0200, Andi Kleen wrote:
> Zwane Mwaikambo <zwane@arm.linux.org.uk> writes:
> 
> >
> > 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? 

Its really not slowdown, but un-necessary complexity, either in terms
of detecting if not to use broadcast, or even like you mention to continue
to perform broadcast, and handle the cleanup of queued ipi,s before 
turning the cpu online.

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

what about case when we need to use logical cpu up/down that is required
for suspend/resume? its really not a platform hotplug, just another feature.

Now you select this by default, and in reallity, all mobile/servers would
end up using this, and all the code to detect hotplug availibty would just
become bit-rotting.

ACPI is pretty static name space, so if you have a 4 socket system and only 
have 2 socket populated, all that you see is 2 present, and 2 not present.

The only indication if hotplug is supported would be presence of _EJD.
Again if this is a NUMA node or wrapped under a bigger module device
its probably required only in the top level object. 

There is nothing there that suggest platform supports hotplug, may be we do
that via mach-*, it seems un-necessary to do all this complexity without
knowing what problem we are solving by doing all this?
> 
> 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.

Why do you call it slow for using mask version? The tsc stats test case
i sent out doesnt show any indication of being slow by any means. Broadcast
and mask came about equal in numbers.

There is just one extra write to local apic, but that doesnt seem to be 
adding anything that significant to be called slow in the grand scheme of 
events.

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

The easier way to fix the problem is fix the source of the problem. So 
if broadcast is introducing an un-necessary race, why not just eliminate that
altogether, when there is really no loss in performance per-se. Instead
of wring whole bunch of code to hande the race doesnt seem appealing.

If we can fix it with less code and there is no *real* loss in performance, 
why not pick a less complicated approach.

The cycle count results doenst seem to indicate any slowness, but freqently
you mention mask varient as slow approach? Doing an extra reg write doesnt
matter, what matters is how long smp_call_function() takes, and that seems
pretty much the same in both instances.

-- 
Cheers,
Ashok Raj
- Open Source Technology Center
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/