Messages in this thread | | | Date | Sun, 29 Feb 2004 16:32:54 +0800 | From | "Michael Frank" <> | Subject | Re: Why no interrupt priorities? |
| |
On Thu, 26 Feb 2004 19:02:59 -0800, Randy.Dunlap <rddunlap@osdl.org> wrote:
> On Thu, 26 Feb 2004 17:36:34 -0800 "Grover, Andrew" <andrew.grover@intel.com> wrote: > > | > On Thursday 26 February 2004 13:30, Arjan van de Ven wrote: > | > > hardware IRQ priorities are useless for the linux model. In > | > linux, the > | > > hardirq runs *very* briefly and then lets the softirq context do the > | > > longer taking work. hardware irq priorities then don't matter really > | > > because the hardirq's are hardly ever interrupted really, > | > and when they > | > > are they cause a performance *loss* due to cache trashing. > | > The latency > | > > added by waiting briefly is going to be really really short > | > for any sane > | > > hardware. > | > | Is the assumption that hardirq handlers are superfast also the reason > | why Linux calls all handlers on a shared interrupt, even if the first > | handler reports it was for its device? > > Somehow I don't think that's the reasoning. > > Is there a safe method to determine that there are no other pending > interrupts on one shared interrupt? i.e., that other devices don't > also have interrupts pending? >
Most interrupt controllers can read back IRQ's to see whether it is active. A shared IRQ would be readback active while any device connected to it desires service.
x86 example for 8259A AT-PIC's Returns the state of IRQ0-15 in ax Note that jmp $+2 is only needed on some old 286/386 hardware to meet (real) 8259A cycle time requirements.
- Intel syntax :)
mov al,0ah out 0a0h,al jmp $+2 in al,0a0h mov ah,al mov al,0ah jmp $+2 out 20h,al jmp $+2 in al,20h
Regards Michael
- 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/
| |