On Fri, 2012-05-04 at 22:14 +0200, Peter Zijlstra wrote: > > Also, we need to fix this problem at the CPU Hotplug level itself, and > > not just for the suspend/resume case. Because, we have had numerous bug > > reports and people complaining about this issue, in various scenarios, > > including those that didn't involve suspend/resume. > > NO, absolutely not and I will NAK any and all such nonsense. WTF is a > cpuset worth if you can run on random other cpus? Sorting your cpuset 'problem' isn't nowhere near enough to make hotplug 'safe'. unplug also destroys task_struct::cpus_allowed. Try it: # schedtool -a 2 $$ # grep Cpus_allowed /proc/self/status Cpus_allowed: 000004 # echo 0 > /sys/devices/system/cpu/cpu2/online # grep Cpus_allowed /proc/self/status Cpus_allowed: ffffff See, hotplug is destructive, it has to be, there's no saying the cpu will every come back. So mucking about trying to make cpusets non-destructive is pointless. The real bug is people using hotplug (for all kinds of stupid stuff) and expecting anything different. -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
