Separate urgent interrupt work from deferred execution

A hardware interrupt can arrive while a CPU is running user code, kernel code, or an idle path. Its source does not have to belong to the task currently running on that CPU. Entry and exit establish the architecture-specific state needed to handle it safely. The handler may acknowledge a device and record completion information, but those details depend on the hardware and driver. The interrupted instruction stream can resume afterward. A notification therefore does not by itself imply that the scheduler selected a different process or that the interrupted thread requested the event.

Interrupt latency describes delay before the relevant handling begins, while handler duration describes time spent doing that work. End-to-end completion latency includes additional stages such as deferred processing, waking a waiter, and waiting for that task to run. Lowering one stage does not automatically lower every stage. A driver that shortens its immediate handler by queueing more work may reduce time spent in that context while increasing completion delay under load. State which interval a measurement covers before using the word latency as if it named a single universal quantity.

Deferral is a scheduling choice, not permission to call any kernel function. A conventional hard-interrupt handler cannot simply sleep waiting for a mutex or external event. Softirq and bottom-half execution also carries restrictions. Threaded interrupt handlers and ordinary threaded workqueues provide different contexts where blocking may be permitted if the particular code path and locks allow it. Read the API contract for the selected mechanism. Do not infer sleepability from a callback's name, from the fact that it runs later, or from an example written for a different kernel configuration.

Linux workqueues make this distinction especially important: ordinary worker threads and bottom-half workqueues are not interchangeable execution environments. Workqueue attributes can affect placement, concurrency, ordering, and forward progress. An ordered workqueue is appropriate when the contract requires that ordering; a concurrency limit alone should not be assumed to establish the same semantics. Teardown must also stop new submissions and synchronize with outstanding callbacks before freeing their state. Moving a callback to a later time can solve an immediate latency problem while introducing an object-lifetime race if ownership ends first.

Suppose device completions arrive faster than a deferred worker can process them. A short immediate handler can keep acknowledging notifications while the downstream queue grows. The backlog represents unfinished work and may retain buffers, references, or requests. Capacity analysis therefore needs both immediate-handler CPU demand and deferred-service throughput, plus bounds on memory and completion age. Interrupt moderation or polling may trade notification rate against batching delay, but whether that helps depends on the device, driver, traffic pattern, and measured application objective. There is no universally optimal interrupt rate independent of workload.

Use the queue lab to predict what happens when the rate of deferred items exceeds their service rate. For a growing run, press Reset, re-set arrival rate to 4 and service rate to 2, predict growth from four items, then press Play or Step. For a separate draining run, reset again, re-set both rates to arrival 4 and service 5, predict that its fresh four-item backlog reaches zero after four seconds, then inspect it. This comparison does not continue the first run's accumulated backlog under new rates. This fluid model has no interrupt masking, CPU affinity, workqueue flags, or kernel callback execution. It illustrates the capacity balance only. A real investigation should correlate notification counts, deferred queue age, CPU usage, and completed requests so that a lower interrupt count is not mistaken for an improvement while unobserved completion work accumulates elsewhere.