Cc: Paul Jackson <pj@...>, <linux-kernel@...>, Con Kolivas <kernel@...>, Derek L. Fults <dfults@...>, devik <devik@...>, Dinakar Guniguntala <dino@...>, Emmanuel Pacaud <emmanuel.pacaud@...>, Frederik Deweerdt <deweerdt@...>, Ingo Molnar <mingo@...>, Matthew Dobson <colpatch@...>, Nick Piggin <nickpiggin@...>, <rostedt@...>, Oleg Nesterov <oleg@...>, Paul E. McKenney <paulmck@...>, Paul Menage <menage@...>, Peter Zijlstra <a.p.zijlstra@...>, Randy.Dunlap <rddunlap@...>, <suresh.b.siddha@...>, Thomas Gleixner <tglx@...>
Yes it used to be somewhat unstable. These days it solid. I'm using it on a
wide range of systems: uTCA Core2Duo, NUMA dual-Opteron, 8way Core2, etc. And
things work as expected.
I forgot to mention that it's not just timers. There are also work queues and
delayed work that have similar side effects (ie they stick to the CPU they
were originally scheduled on). Hotplug cleans all that stuff very nicely.
btw I would not call it a hack. ie Using cpu hotplug for isolation purposes.
By definition hotplug must be able to migrate _everything_ running on the cpuN
when it goes off-line, otherwise it simply won't work. And that's exactly what
we need for the isolation too (migrate everything running on a cpuN to other
cpus).
Agree. That's why I submitted the removal patch along with those fixes ;-).
Thanx.
That exactly where the conflict is. Lets say you boot with isolcpus=2 (ie cpu2
is not load balanced), then you add cpu2 along with cpu3 to cpuset N and
enable load balancing in cpusetN. In that case cpu2 will still remain
unbalanced which is definitely a wrong behaviour.
Max
--
