Interrupt, Interrupt Latency, and IRQ - 2017
In systems programming, an interrupt is a signal to the processor.
It can be emitted either by hardware or software indicating an event that needs immediate attention.
Interrupts are a commonly used technique in real-time computing and such a system is said to be interrupt-driven.
|Hardware||Software (Exception/Trap)||Software (Instruction set)|
|Interrupt Request(IRQ) sent from device to processor.||Exception/Trap sent from processor to processor, caused by an exceptional condition in the processor itself.||A special instruction in the instruction set which causes an interrupt when it is executed.|
- Hardware interrupt
A hardware interrupt is a signal which can tell the CPU that something happen in hardware device, and should be immediately responded. Hardware interrupts are triggered by peripheral devices outside the microcontroller. An interrupt causes the processor to save its state of execution and begin execution of an interrupt service routine.
Unlike the software interrupts, hardware interrupts are asynchronous and can occur in the middle of instruction execution, requiring additional care in programming. The act of initiating a hardware interrupt is referred to as an interrupt request (IRQ).
- Software interrupt
Software interrupt is an instruction which cause a context switch to an interrupt handler similar to a hardware interrupt. Usually it is an interrupt generated within a processor by executing a special instruction in the instruction set which causes an interrupt when it is executed.
Another type of software interrupt is triggered by an exceptional condition in the processor itself. This type of interrupt is often called a trap or exception.
Unlike the hardware interrupts where the number of interrupts is limited by the number of interrupt request (IRQ) lines to the processor, software interrupt can have hundreds of different interrupts.
Interrupt latency refers primarily to the software interrupt handling latencies. In other words, the amount of time that elapses from the time that an external interrupt arrives at the processor until the time that the interrupt processing begins. One of the most important aspects of kernel real-time performance is the ability to service an interrupt request (IRQ) within a specified amount of time.
picture source: Measuring interrupt latency - Mentor Graphics
Here are the sources contributing the interrupt latency (abstracts from Reduce RTOS latency in interrupt-intensive apps):
- Operating system (OS) interrupt latency
An RTOS must sometimes disable interrupts while accessing critical OS data structures. The maximum time that an RTOS disables interrupts is referred to as the OS interrupt latency. Although this overhead will not be incurred on most interrupts since the RTOS disables interrupts relatively infrequently, developers must always factor in this interrupt latency to understand the worst-case scenario.
- Low-level interrupt-related operations
When an interrupt occurs, the context must be initially saved and then later restored after the interrupt processing has been completed. The amount of context that needs to be saved depends on how many registers would potentially be modified by the ISR (Interrupt Service Routine).
- Enabling the ISR to interact with the RTOS
An ISR will typically interact with an RTOS by making a system call such as a semaphore post. To ensure the ISR function can complete and exit before any context switch to a task is made, the RTOS interrupt dispatcher must disable preemption before calling the ISR function. Once the ISR function completes, preemption is re-enabled and the application will context switch to the highest priority thread that is ready to run. If there is no need for an ISR to make an RTOS system call, the disable/enable kernel preemption operations would again add overhead. It is logical to handle such an ISR outside of the RTOS.
- Context switching
When an ISR defers processing to an RTOS task or other thread, a context switch needs to occur for the task to run. Context switching will still typically be the largest part of any-RTOS related interrupt processing overhead.
- IRQ (Interrupt Request)
An (or IRQ) is a hardware signal sent to the processor that temporarily stops a running program and allows a special program, an interrupt handler, to run instead. Interrupts are used to handle such events as data receipt from a modem or network, or a key press or mouse movement.
- FIQ (Fast Interrupt Request)
An FIQ is just a higher priority interrupt request, that is prioritized by disabling IRQ and other FIQ handlers during request servicing. Therefore, no other interrupts can occur during the processing of the active FIQ interrupt.
*Most of the requests are spending time just waiting due to I/Os
Ph.D. / Golden Gate Ave, San Francisco / Seoul National Univ / Carnegie Mellon / UC Berkeley / DevOps / Deep Learning / Visualization