Ingo Molnar <[EMAIL PROTECTED]> wrote: > > > * Andrew Morton <[EMAIL PROTECTED]> wrote: > > > OK, but most of the new ones are unneeded with CONFIG_PREEMPT=y. I'm > > still failing to see why a non-preempt, voluntary preemption kernel > > even needs to try to be competitive with a preemptible kernel? > > the reason is difference in overhead (codesize, speed) and risks (driver > robustness).
I don't recall any testing results which showed a significant performance difference from CONFIG_PREEMPT. > We do not want to enable preempt for Fedora yet because it > breaks just too much stuff What stuff? > (Long-term i'd like to see preempt be used unconditionally - at which > point the 10-line CONFIG_VOLUNTARY_PREEMPT Kconfig and kernel.h change > could go away.) We'll never get there if people don't at least report the broken "stuff", let alone fix it. And "stuff" is already broken on SMP, yes? Your voluntary preempt patch will need to borrow preempt_spin_lock() and preempt_write_lock() btw - otherwise it won't improve worst-case latencies on SMP at all.
