A hardware interrupt is a signal from a device to the operating system. It interrupts the CPU’s current work and invokes an OS-registered handler. A network interface controller (NIC), for example, can signal that a packet has arrived. Interrupts let the OS respond to device events, but they can also interrupt a latency-sensitive application at unpredictable times. section 7.5.2 section 2.3.4
The hardware handler is only part of the cost. Operating systems often handle the hardware signal quickly and defer further processing to kernel work, sometimes called software interrupts. For an incoming network packet, protocol processing may then run on a different CPU from the application thread that receives the resulting message. This deferred work can interfere with application latency much like a background task. section 7.5.2 section 3.3.1
For low-latency work, choose how device events and their processing share CPU time:
- Consider CPU placement: isolate interrupt processing on dedicated CPUs, or colocate it with application threads on the same CPU. section 3.3.1
- Consider polling: a driver can check for events rather than wait for each interrupt. This avoids some interrupt overhead but may do unnecessary work when repeatedly checking an idle device. section 7.5.2
- Account for event rate: busy network or storage devices can produce enough interrupts to cause latency spikes; interrupt affinity and coalescing are OS mitigation techniques. section 2.3.4
A packet arriving at a NIC
A packet enters a NIC receive queue. The NIC can interrupt the kernel to announce its arrival, but interrupting for every packet would be inefficient. Linux network processing therefore uses polling for incoming packets and switches to interrupt-driven operation when network traffic stops. Software-interrupt processing and protocol handling still need CPU time before the application can process the message. section 3.3.1
