> >>> It would also increase the latency of CPU-hotunplug operations. > >> > >> Is that a big deal? > > > > I thought that was the whole deal with this patchset - making cpu > > hotunplugs lighter and faster mostly for powersaving. That said, just > > removing stop_machine call would be a pretty good deal and I don't > > know how meaningful reducing CPU hotunplug latency is. Srivatsa? > > > > Keeping the hotunplug latency is important for suspend/resume, where > we take all non-boot CPUs in a loop. That's an interesting use-case > where intrusiveness doesn't matter much, but latency does. So yes, > making CPU hotplug faster is also one of the goals of this patchset. If you are removing all but one of the cpu, the you only need one rcu cycle (remove everything from the list first). I'd also guess that you can't suspend a cpu until you can sleep the process that is running on it - so if a process has pre-emption disabled you aren't going to complete suspend until the process sleeps (this wouldn't be true if you suspended the cpu with its current stack - but if suspend is removing the non-boot cpus first it must be doing so from the scheduler idle loop). If you are doing suspend for aggressive power saving, then all the processes (and processors) will already be idle. However you probably wouldn't want the memory accesses to determine this on a large NUMA system with 1024+ processors. David -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
