Re: spurious 8259A interrupt

[Anton Blanchard]

> Indeed.  But why?  What's the advantage?

We enable IRQs during IRQ processing on ppc64 for one reason. We set the
IPI priority higher than normal IRQs so we can service it as soon as
possible and the calling cpu can move on.

> E.g. if the irq 1 handler takes a long time, multiple irq 2
> interrupts can be serviced during it.
> 
> But that doesn't work, when there are no meaningful hardware
> priorities: an irq 2 handler can be interrupted by the long irq 1
> handler, maybe before it gets to do anything useful, and then the irq
> 2 interrupt doesn't have low latency.

Yeah. We have a huge number of possible priorities on some ppc64
interrupt controllers but it turns out we dont have a concept of
priority or tolerance of latency for devices in Linux. I could see us
wanting serial IRQs to have a higher priority than disk IRQs if the
information was there for us to exploit.

In the end we map all IRQs to the same priority on ppc64 which means we
will never take a recursive IRQ due to devices.

Anton
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/