Always remember, you are at most yourself; and, you are at least yourself.: Key Benefits of the I/O APIC

The following contains extracts from MSDN and wikipedia.com.

The Intel APIC Architecture is a system of Advanced Programmable Interrupt Controllers (APICs) designed by Intel for use in Symmetric Multi-Processor (SMP) computer systems. It was originally implemented by the Intel 82093AA and 82489DX, and is found in most x86 SMP motherboards. It is one of several attempts to solve interrupt routing efficiency issues in multiprocessor computer systems.

There are two components in the Intel APIC system, the Local APIC (LAPIC) and the I/O APIC. The LAPIC is integrated into each CPU in the system, and the I/O APIC is used throughout the system's peripheral buses. There is typically one I/O APIC for each peripheral bus in the system. In original system designs, LAPICs and I/O APICs were connected by a dedicated APIC bus. Newer systems use the system bus for communication between all APIC components.

In systems containing an 8259 PIC, the 8259 may be connected to the LAPIC in the system's bootstrap processor (BSP), or to one of the system's I/O APICs.

Sharing Interrupts Is Bad

Edge-triggered Interrupts. With any interrupt controller, an edge-triggered interrupt is a one-time event. There is no notion of feedback. The operating system never really knows when it has handled the situation that caused the interrupt; it can only know that an event happened sometime in the recent past. Therefore, the only rational response to an edge-triggered interrupt is to run all the Interrupt Service Routines (ISRs) associated with that vector once, with the hope that this will resolve it.

This situation is especially sketchy when dealing with hardware that doesn't give any real indication of why it interrupted, a common occurrence among today's edge-triggering devices. The result is that the operating system can miss interrupts delivered in the interval between when an interrupt is first taken and when it is acknowledged.

With an 8259 PIC interrupt controller, the situation is even worse. The 8259 is inherently unreliable, particularly when coupled with an actual ISA bus. The operating system software will see a number of spurious interrupts, some of which show up on different vectors than the original signal.

Level-triggered Interrupts. The protocol of a level-triggered interrupt is as follows:
•Whenever the interrupt signal is held low (for active-low interrupts, which are the most common), the interrupt controller will generate an interrupt.
•If the interrupt is acknowledged and the signal is still low, then the interrupt controller will generate another interrupt.
This is good for sharing, because it confirms that the operating system handled the interrupting device. The algorithm is:
1.Take an interrupt.
2.Run the first ISR in the chain.
3.If that ISR returns TRUE (meaning that it handled an interrupt), then the operating system will ACK the interrupt and quit.
4.If that ISR returns FALSE, then run the next ISR in the chain and go to Step 3.

An excellent example of the problem case comes when there are twelve devices all chained on one vector, common for a docked laptop. Every time the operating system takes an interrupt, the operating system must run as many as twelve ISRs before it begins to handle the condition that caused the interrupt.

more on this question, http://www.microsoft.com/whdc/system/sysperf/IO-APIC.mspx