Messages in this thread | | | Date | Wed, 05 Jul 2000 17:32:09 -0600 | From | "Jeff V. Merkey" <> | Subject | Re: spinlocks() are severely broken in 2.2.X and 2.4.X for modules |
| |
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/
| |