Cc: Peter Zijlstra <a.p.zijlstra@...>, Paul Jackson <pj@...>, <linux-kernel@...>, Con Kolivas <kernel@...>, Derek L. Fults <dfults@...>, devik <devik@...>, Dimitri Sivanich <sivanich@...>, 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@...>, Randy.Dunlap <rddunlap@...>, <suresh.b.siddha@...>, Thomas Gleixner <tglx@...>
Not sure what you meant here. Stuff that I listed has nothing to do with user
process scheduling.
That's why I mentioned "first init" script. You can create a simple init.d
compliant script that runs with priority 0 (see /etc/init.d/network for
example). That should be early enough.
How does isolcpu= boot option helps in this case ?
I suppose the closes option is maxcpus=. We can probably add ignorecpus= or
something to handle your use case but it has nothing to do with isolcpus=.
So do custom init.d scripts.
I think you're missing the point here. It's like saying
"Lets not switch to electric cars because I use gasoline to kill weeds".
As I mentioned before, cpus listed in the isolcpus= boot option will still
handle hard-/soft- irqs, kernel work, kernel timers. You are much better off
using cpu hotplug (ie putting bad cpu offline). Feel free to propose
ignorecpus= option in a separate thread.
Max
--
