Interrupt handling processes a hardware or software interrupt by suspending current CPU execution, saving state, and invoking an interrupt handler. Hardware interrupts arise when devices need attention, such as after a network packet arrives, a disk operation completes, or a timer fires. section 2.3.4
The handler introduces interrupt latency, typically measured in microseconds, and arrives at unpredictable times. Frequent interrupts can therefore create tail-latency spikes, especially for applications competing with busy network or storage devices. section 2.3.4 section 2.3
Latency-sensitive systems commonly manage interrupt handling through several trade-offs:
- Configure interrupt affinity so selected CPUs handle device interrupts without interfering with application threads. section 7.5.2
- Use interrupt coalescing to reduce interrupt overhead, accepting that batching can delay individual events. section 2.3.4
- Replace interrupts with polling when controlling event-check timing and thread scheduling matters more than avoiding queries with no events. section 2.3.4 section 7.5.2
- Partition CPUs between application threads and interrupt processing so both can run in parallel. section 7.5.2
Network packet arrival
A network interface can notify the CPU with an interrupt whenever a packet arrives, or a driver can poll the interface periodically. Interrupts avoid repeated empty queries but can preempt application code unpredictably; polling provides more control over when the work occurs. section 2.3.4 section 7.5.2
