On Thu, 2011-02-24 at 20:11 +0000, Alan Cox wrote: > > Anybody who is interested in the latency of cpu hotplug is deluding > > himself, also cpu hotplug is _NOT_ a power management feature, so the > > rest of your justification just disappeared as well. > > Actually CPU hotplug is a power management feature on some devices where > you need to shutdown one of the cores to enter low power modes. Aren't we confusing things here? Surely simply idling a core is good enough? Why would we want to go through the whole CPU hotplug dance simply to enter a low power state? > Remember we use it as part of the suspend paths and various processors > nowdays drop into a suspend to RAM type state on CPU idling. Which would illustrate the above point. CPU hotplug is a terribly expensive op, and doing so from idle is really utterly ridiculous (nor can we, idle is not supposed to schedule and cpu-hotplug needs to schedule) Why can't we do these things from the normal idle path, presumably these state transitions are 'fast', so we can implement them as normal idle modes. The scheduler has (due to power7 support) the ability to favour lower cpu nrs when placing tasks, so idle !bsp (assuming cpu0 is the bsp) can drop into their special state, and then when the bsp goes idle it can do whatever it needs to do. All that needs is to make sure smp_send_reschedule() can wake !bsp cores from their special sleep state, but that's all arch code anyway. I really see no reason to conflate cpu-hotplug and idle/power-states. -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
