Re: [patch 0/4] CPU hot-plug support for x86_64

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

On Mon, May 23, 2005 at 06:40:46PM +0200, Andi Kleen wrote:
> On Fri, May 20, 2005 at 03:16:22PM -0700, Ashok Raj wrote:
> > Andi: You had mentioned that you would not prefer to replace the broadcast IPI
> >       with the mask version for performance. Currently this seems to be the
> > 	  most optimal way without putting a sledge hammer on the cpu_up process.
> 
> I already put a sledgehammer to __cpu_up with that last

Yours was a good sledge hammer :-) the way it should have been done
but carried legacy boot from i386 that wasnt pretty. The one iam referring
to is pretty darn slow, and think it wont be liked my many to slow down the
system just to add a new cpu.

> patch. Some more hammering surely wouldnt be a big issue. Unlike i386
> we actually still have a chance to test all relevant platforms, so I 
> dont think it is a big issue.
> 
> What changes did you plan?

The only other workable alternate would be to use the stop_machine() 
like thing which we use to automically update cpu_online_map. This means we 
execute a high priority thread on all cpus, bringing the system to knees before
just adding a new cpu. On very large systems this will definitly be 
visible.

Just curious, what performance impact did you allude to that would be lost
if we dont use the shortcut IPI version?

> 
> P.S.: An alternative would be to define a new genapic subarch that
> you only enable when you detect cpuhotplug support at boot.
> 

There is nothing currently there to find out if something is hotplug
capable in a generic way at platform level, other than adding cmdline options 
etc.  

Also FYI: ACPI folks are experimenting using CPU hotplug to suspend/resume
support. So hotplug support may be required not just on platforms that support
it but also for other related uses.

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/