Interrupt-driven input-output (source code)

= Interrupt-driven input-output

In <interrupt-driven input-output>, a device signals an <interrupt> when attention is needed, letting the <CPU> avoid repeatedly checking an idle device. The <interrupt handler> determines what happened and arranges the required work; notification itself does not move the payload. <DMA> can supply that separate data-transfer mechanism.

For a toy comparison, let events occur at times $2,5,9$. Ideal <interrupt> notification happens at those same times, while <polled input-output> at $0,2,4,6,8,10,12$ detects them at $2,6,10$. The polling delays are $0,1,1$; ideal notification delays are all zero. Events are assumed to remain pending, with a simultaneous event visible to a poll. The chart is a model, not a measurement: it excludes <interrupt> delivery and dispatch latency, <interrupt handler> service time, and polling overhead. Its zero-delay row is not a real-hardware guarantee.

\Image[/interrupt-versus-polling-timeline.png]
{title=Ideal <interrupt> notification versus periodic <polled input-output> for three persistent device events}

The useful idea is to spend attention when something changes. Sparse events can leave long stretches for useful <CPU> work instead of busy checks. At high event rates, repeated entry and service overhead can consume that saving. Batching notifications can reduce their frequency while delaying some events; switching to <polled input-output> during active periods is another option. No strategy is universally faster. https://pages.cs.wisc.edu/~remzi/OSTEP/file-devices.pdf[Arpaci-Dusseau and Arpaci-Dusseau, OSTEP chapter 36, section 36.4: interrupt costs and coalescing]{ref}

The <Linux kernel>'s NAPI mechanism is a concrete combination: an <interrupt> normally schedules event processing, which polls for work with a receive budget. Further <interrupts> remain masked during that polling, and are enabled again when polling finishes. NAPI also supports busy polling; the exact processing context and configuration vary. This is a documented <Linux kernel> design, not a requirement on every <operating system>. https://docs.kernel.org/networking/napi.html[Linux kernel documentation, NAPI: basic operation, datapath API, scheduling and IRQ masking]{ref}