Re: [PATCH] 2.4.0-prerelease: preemptive kernel.

[ludovic fernandez <ludovic.fernandez@sun.com>]

Daniel Phillips wrote:

>
> The key idea here is to disable preemption on spin lock and reenable on
> spin unlock.  That's a practical idea, highly compatible with the
> current way of doing things.  Its a fairly heavy hit on spinlock
> performance, but maybe the overall performance hit is small.  Benchmarks
> are needed.
>

I'm not sure the hit on spinlock is this heavy (one increment for lock
and one dec + test on unlock), but I completely agree (and volonteer)
for benchmarking. I'm not convinced a full preemptive kernel is something
interesting mainly due to the context switch cost (actually mmu contex switch).
Benchmarking is a good way to get a global overview on this.
What about only preemptable kernel threads ?

>
> A more ambitious way to proceed is to change spinlocks so they can sleep
> (not in interrupts of course).  There would not be any extra overhead
> for this on spin_lock (because the sleep test is handled off the fast
> path) but spin_unlock gets a little slower - it has to test and jump on
> a flag if there are sleepers.
>

I may be tired but I believe you're focusing on SMP architecture ?
This code simply defer the preemption at the end of the spinlock/lock
section. I don't see how you can easily mix sleeping lock and this
mechanism.

Ludo.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/