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

[Nigel Gamble]

On Thu, 4 Jan 2001, Andi Kleen wrote:
> On Thu, Jan 04, 2001 at 08:35:02AM +0100, Daniel Phillips wrote:
> > 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
> 
> Imagine what happens when a non sleeping spinlock in a interrupt waits 
> for a "sleeping spinlock" somewhere else...
> I'm not sure if this is a good idea. Sleeping locks everywhere would
> imply scheduled interrupts, which are nasty. 

Yes, you have to make sure that you never call a sleeping lock
while holding a spinlock.  And you can't call a sleeping lock from
interrupt handlers in the current model.  But this is easy to avoid.

> I think a better way to proceed would be to make semaphores a bit more 
> intelligent and turn them into something like adaptive spinlocks and use
> them more where appropiate (currently using semaphores usually causes
> lots of context switches where some could probably be avoided). Problem
> is that for some cases like your producer-consumer pattern (which has been
> used previously in unreleased kernel code BTW) it would be a pessimization
> to spin, so such adaptive locks would probably need a different name.

Experience has shown that adaptive spinlocks are not worth the extra
overhead (if you mean the type that spin for a short time
and then decide to sleep).  It is better to use spin_lock_irqsave()
(which, by definition, disables kernel preemption without the need
to set a no-preempt flag) to protect regions where the lock is held
for a maximum of around 100us, and to use a sleeping mutex lock for
longer regions.  This is what I'm working towards.

Nigel Gamble                                    [e-mail]
Mountain View, CA, USA.                         http://www.nrg.org/