On Thu, 9 Mar 2000 yodaiken@fsmlabs.com wrote:
> The result is that we don't need the extra spinlock, but we freeze the
> IOAPIC until the ack. I don't know whether this freezes all irqs or
> "only" irqs that are lower hardware priority, but it's a major change
> in irq semantics and one with interesting performance implications.
it 'freezes' no IRQ at all, the IO-APIC can have any number of outstanding
IRQs. The IO-APIC will not post any further IRQs of that vector, but that
is a welcome thing: most IRQ handlers do a loop over some status register,
so multiple requests can be coalesced. The local-APIC only accepts
higher-priority interrupts while unacked, but this was an intended change:
IRQ handlers should be atomic and must not rely on other IRQs arriving
during the handler. (This APIC handling method is btw. similar to what NT
uses.)
-- mingo
-
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 : Wed Mar 15 2000 - 21:00:17 EST