On Thu, Oct 10, 2013 at 10:48 AM, Andrew Morton <a...@linux-foundation.org> wrote: > > Yes, I'd have thought that the cases where a CPU is fiddling with > another CPU's percpu data with preemption enabled would be rather rare. > > I can't actually think of any off the top. Are there examples we can > look at?
You can't do that right now - since you have to get the cpu list. So it may not be with "preemption enabled", but it should always be under the locking provided by get_online_cpus().. That one allows sleeping, though. I personally would *love* to make CPU hotplug be a lockless thing entirely. But I detest stop-machine too, because it has these really annoying properties. So if we want to make it zero-cost to look at online CPU data, can we avoid even the stop-machine synchronization, instead saying that the cpu hotplug bitmap is updated completely locklessly, but if you see a bit set, the data associated with that CPU is guaranteed to still be available. IOW, just use "RCU semantics" on a per-bit level. When we offline a CPU, we do clear_bit(cpu, cpu_online_mask); rcu_synchronize(); .. now we can free all the percpu data and kill the CPU .. without any locking anywhere - not stop-machine, not anything. If somebody is doing a "for_each_cpu()" (under just a regular rcu_read_lock()) and they see the bit set while it's going down, who cares? The CPU is still there, the data is accessible.. I'm sure there's some reason the above wouldn't work, but the above would seem to be pretty optimal. Why do we really force this big locking thing? The new patches make that locking _smarter_, but it's still a damn big lock. Could we possibly go _beyond_ the lock? Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/