Jamie,
On NetWare we saw performance gains be turning on interrupts inside a
spinlock while it was spinning (provided no reentrant code paths could
cause a deadlock. It allowed driver interrupts to run while the lock
was spinning. Measured peformance improvement was around 3%. Something
to think about.
Jeff
Jamie Lokier wrote:
>
> Jeff V. Merkey wrote:
> > However, the issues raised relative to the cross platform lock/irq
> > function semantics raised by folks are significant. Typically on
> > Intel, you want to disable interrupts around a spinlock/unlock pair for
> > any code paths that can be re-entered via an interrupt, timer, etc.
>
> > Most spinlock implementations I've seen may also enable interrupts while
> > they are spining, then disable them inside the lock
>
> Hmm, that's a nice idea. Does it improve performance?
>
> > ... to avoid deadlocks caused by an interrupt breaking into a code
> > section holding the spinlock because interrupts were enabled.
> > Whatever semantic is used, however, should be general enough to allow:
> >
> > ints_off()
> > spinlock()
> >
> > spinunlock()
> > ints_on()
> >
> > or something to that effect for all the SMP capable architectures. :-)
>
> spin_lock() should leave the irq state well alone, whether it spins or
> not. The only thing that may be interesting to change is
> spin_lock_irqsave() -- that could be made to behave "as if" interrupts
> are not disabled until the moment the lock is actually acquired.
> (I.e. by restoring the irq state while spin-reading).
>
> I don't know if there are any performance gains, or fairness issues that
> may arise. But as far as lock safety goes, that is perfectly safe. It
> simply changes the timing.
>
> -- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Jul 07 2000 - 21:00:17 EST