On 06/26/2013 07:59 PM, David Laight wrote: >> Once stop_machine() is gone from the CPU offline path, we won't be able >> to depend on disabling preemption to prevent CPUs from going offline >> from under us. > > Could you use an rcu-like sequence so that disabling pre-emption > would be enough? > > Something like rebuilding the cpu list, then forcing yourself > to run on all the cpu. > Certainly, and we had debated schemes similar to that (including schemes invoking synchronize_sched() itself) in earlier discussions. (But IIRC even those schemes required converting call-sites from preempt_disable() to get/put_online_cpus_atomic(), to properly synchronize). > That would be far less intrusive. > But that would increase the latency of hotplug operations like Paul pointed out, and that in turn is not good for use-cases such as suspend/resume, where we take all non-boot CPUs offline in a loop. (That would mean executing the above logic num_online_cpus() times!). So we started hunting for ideas that can make the hotplug writer side not only less intrusive, but also remain fast. That's how the later designs evolved. Regards, Srivatsa S. Bhat -- 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