Messages in this thread | | | Date | Sat, 20 Mar 2004 01:04:55 +1100 | From | Anton Blanchard <> | Subject | Re: spurious 8259A interrupt |
| |
> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |