Re: More than 8 CPUs detected and CONFIG_X86_PC cannot handle it on 2.6.16-rc6

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

On Mon, Mar 13, 2006 at 02:22:23PM -0800, Andrew Morton wrote:
> >   config HOTPLUG_CPU
> >   	bool "Support for hot-pluggable CPUs (EXPERIMENTAL)"
> >  -	depends on SMP && HOTPLUG && EXPERIMENTAL && !X86_VOYAGER
> >  +	depends on SMP && HOTPLUG && EXPERIMENTAL && !X86_VOYAGER && !X86_PC
> >   	---help---
> >   	  Say Y here to experiment with turning CPUs off and on.  CPUs
> >   	  can be controlled through /sys/devices/system/cpu.
> 
> Longer term, it appears that we need to do some Kconfig and C work to
> separate out the HOTPLUG_CPU infrastructure which swsusp needs from actual
> CPU hotplugging.

The needs are not any different. Both (swsusp and cpu hotplug) both require
logical cpu offlining which is what CONFIG_HOTPLUG_CPU does.

Physical cpu hotplug is enabled by CONFIG_ACPI_HOTPLUG_CPU.

> 
> What _is_ this IPI problem anyway?  Can't send point-to-point IPIs to
> offlined CPUs?  (Don't do that then?) Or do broadcast IPIs go wrong, or
> what?

Its not the point-to-point..we do that only to wake a CPU, but thats done
in flat physical mode always.

When we do smp_call_function() under X86_PC we use logical flat mode. 
This sends a broadcast IPI by using a shortcut message. This is bad, since 
the offline cpu may also receive it and process just when we bring the cpu 
online. 

send_IPI_allbutself() and send_IPI_all() versions that use the shortcut
values are the ones to avoid. 

> 
> And does it affect pretend-x86-hotplug, or is it only affecting real hotplug?
> 
its no more pretend-x86, in the past we used to put the cpu in idle(), 
now we do put the cpu in halt and bring back by another startup ipi, just like 
boot sequence, both for x86 and x86_64.

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