Interrupt latency in real-time and general-purpose systems

Contributing factors

Several hardware and software elements determine interrupt latency. At the hardware level, delays arise from the processor pipeline, the interrupt controller, and the time required to acknowledge and vector to the handler. The state of the CPU (for example, whether it is in a low-power state or executing a long instruction) also affects delay. At the software level, latency depends on whether interrupts are masked or disabled, the operating system's interrupt handling model, and how quickly context can be saved and restored.

• Hardware sources: interrupt controller arbitration, bus contention, and device response time.
• Software sources: interrupt masking, critical sections, priority levels, and non-preemptible kernel code.
• System-level effects: interrupt nesting, deferred processing, and interrupt storms.

Measurement and metrics

Interrupt latency is typically measured with logic analyzers, hardware timers, or high-resolution timestamps: the time from the device's interrupt signal to the first instruction of the Interrupt Service Routine (ISR). Related metrics include worst-case latency (important for hard real-time guarantees) and jitter (variation between occurrences). Designers often distinguish between the latency to start servicing an interrupt and the total time to complete device processing, which may include deferred work in threads or bottom halves.

Mitigation techniques

Common strategies to reduce or bound latency include assigning higher priority to time-critical interrupts, minimizing the amount of work done in ISRs (deferring complex processing to scheduled tasks), enabling nested interrupts, and avoiding long non-preemptible sections in kernel or driver code. Hardware support such as faster interrupt controllers and features that reduce context-save time also help. In software, careful use of locking, priority inheritance, and lock-free algorithms can lessen blocking delays.

History, applications and distinctions

The importance of interrupt latency grew with the rise of embedded control and digital communications where predictable response times are essential. Early microcomputer systems had relatively coarse latency due to simple hardware and monolithic kernels; modern designs in avionics, automotive systems, and industrial control emphasize bounded latency through specialized RTOS features. It is important to distinguish interrupt latency from overall system response time: the former begins at the interrupt signal, while the latter may include queuing, higher-level scheduling, and device I/O completion. Also note the distinction between hard real-time systems, where missed deadlines are unacceptable, and soft real-time systems, where occasional latency spikes are tolerable.

Practical evaluation of latency often involves instrumenting the device or driver, using synthetic interrupt generators, and analyzing both average and worst-case behavior. When implementing drivers for a peripheral, engineers typically ensure that ISRs are kept minimal and that any long-running work is programmed into deferred handlers or threads managed by the operating system. Understanding how the CPU and interrupt controller interact helps in selecting hardware and tuning software to meet latency objectives.