Re: [Fwd: problem involving wait_on_bh]

Andrea Arcangeli (andrea@suse.de)
Sun, 19 Dec 1999 16:23:21 +0100 (CET)


On Sun, 19 Dec 1999, Alan Cox wrote:

>
> irq_begins
> grab_lock_irqsave()
> grab_lock()
> [spins]
> disable_irq()
> [spins waiting for irq exit]

The above make not a lot of sense to me. The only point for disable_irq is
to avoid the irqsave in the global_lock_irqsave on the left.

Right code that doesn't want to clear irq for a long time should do:

disable_irq_nosync();
spin_lock();
irq_enter
spin_lock;

Using disable_irq_nosync() is faster (achieve the best parallelism
possible as we'll block only on the spinlocks) but disable_irq() could be
used too safely. In the example a slower disable_irq() is not necessary
because the critical section is protected by a spinlock also inside the
irq handler.

Disabling irqs (mainly the ISA irqs) is slower than a cli, so if the
critical section is small and there's no I/O the strightforward irqsave
way is faster than disabling one only irq.

Andrea

-
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/