On Wed, 1 Mar 2000, Linus Torvalds wrote:
>If you do that, then that just shows that the rest of the interrupt
>subsystem is doing something wrong. You should not have had a pending
Nothing goes wrong. What happens without the IRQ_LEVEL bit is this:
CPU0 CPU1
------------------ --------------------
do_IRQ(27, ...)
do_IRQ(27, ...)
spin_lock();
spin_lock() spinning
->ack that is a disable_irq(27)
set pending bit
irq not disabled and not in progress
so set irq_inprogress bit and clear
pending bit
spin_unlock();
got the lock finally
set pending bit
^^^^^^^^^^^^^^^
irq is in progress so goto out
->end now correctly does
nothing because irq is
inprogress
spin_unlock();
handle_IRQ_event();
spin_lock();
pending bit is set, so clear it and
iff the new IRQ_LEVEL bit is _not_ set,
then re-run handle_IRQ_event()
...
The IRQ_LEVEL bit prevents that second run to happen if it wasn't
necessary.
And no, we can't delegate the cpu selection to the hardware. That's why
smp irq affinity is much more important for alpha where there aren't only
i/d cache issues (and RT issues when we'll have task cpu binding), but it
also risks to get contention on the irq_desc lock.
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/
This archive was generated by hypermail 2b29 : Tue Mar 07 2000 - 21:00:10 EST