Messages in this thread | | | Date | Wed, 1 Mar 2000 20:21:40 +0100 (CET) | From | Andrea Arcangeli <> | Subject | Re: new IRQ scalability changes in 2.3.48 |
| |
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/
| |