Editing Interrupt latency

{{See also|Latency (engineering)}}
{{More citations needed|date=June 2019}}
{{Use dmy dates|date=June 2019|cs1-dates=y}}
In computing, '''interrupt latency''' refers to the delay between the start of an Interrupt Request (IRQ) and the start of the respective Interrupt Service Routine (ISR).<ref name="Yiu_2016_Latency"/> For many operating systems, devices are serviced as soon as the device's [[interrupt handler]] is executed. Interrupt latency may be affected by [[microprocessor]] design, [[interrupt controller]]s, [[Interrupt#Masking|interrupt masking]], and the [[operating system]]'s (OS) interrupt handling methods.<ref>{{Cite journal|last1=Lin|first1=Feng|last2=Ashley|first2=David T.|last3=Burke|first3=Michael J.|last4=Heymann|first4=Michael|date=1999|title=A Hybrid System Solution of the Interrupt Latency Compatibility Problem|journal=SAE Transactions|volume=108|pages=2112–2125|jstor=44733861|issn=0096-736X}}</ref>

==Background==
There is usually a trade-off between interrupt latency, [[throughput]], and processor utilization. Many of the techniques of [[microprocessor|CPU]] and [[operating system|OS]] design that improve interrupt latency will decrease throughput and increase processor utilization. Techniques that increase throughput may increase interrupt latency and increase processor utilization. Lastly, trying to reduce processor utilization may increase interrupt latency and decrease throughput.

Minimum interrupt latency is largely determined by the [[interrupt controller]] circuit and its configuration. They can also affect the [[jitter]] in the interrupt latency, which can drastically affect the [[Real-time computing|real-time]] [[Scheduling (computing)|schedulability]] of the system. The [[Intel APIC architecture]] is well known for producing a huge amount of interrupt latency jitter.{{citation needed|date=November 2015}}

Maximum interrupt latency is largely determined by the methods an OS uses for interrupt handling. For example, most processors allow programs to disable interrupts, putting off the execution of interrupt handlers, in order to protect [[critical section]]s of code. During the execution of such a critical section, all interrupt handlers that cannot execute safely within a critical section are blocked (they save the minimum amount of information required to restart the interrupt handler after all critical sections have exited).  So the interrupt latency for a blocked interrupt is extended to the end of the critical section, plus any interrupts with equal and higher priority that arrived while the block was in place.

Many computer systems require low interrupt latencies, especially [[embedded system]]s that need to [[Control system|control]] machinery in real-time.  Sometimes these systems use a [[real-time operating system]] (RTOS). An RTOS makes the promise that no more than a specified maximum amount of time will pass between executions of [[subroutine]]s. In order to do this, the RTOS must also guarantee that interrupt latency will never exceed a predefined maximum.

==Considerations==
Advanced interrupt controllers implement a multitude of hardware features in order to minimize the overhead during [[context switch]]es and the effective interrupt latency. These include features like:

* Minimum jitter through non-interruptible instructions<ref name="Yiu_2016_Latency"/>
* Zero wait states for the memory system<ref name="Yiu_2016_Latency"/>
* Switchable register banks<ref name="Yiu_2016_Latency"/>
* Tail chaining<ref name="Yiu_2016_Latency"/>
* Lazy stacking<ref name="Yiu_2016_Latency"/>
* Late arrival<ref name="Yiu_2016_Latency"/>
* Pop preemption<ref name="Yiu_2016_Latency"/>
* Sleep-on-exit feature<ref name="Yiu_2016_Latency"/>

Also, there are many other methods hardware may use to help lower the requirements for shorter interrupt latency in order to make a given interrupt latency tolerable in a situation. These include buffers, and [[flow control (data)|flow control]]. For example, most network cards implement transmit and receive [[ring buffer]]s, interrupt rate limiting, and hardware flow control. Buffers allow data to be stored until it can be transferred, and flow control allows the network card to pause communications without having to discard data if the buffer is full.

Modern hardware also implements interrupt rate limiting. This helps prevent [[interrupt storm]]s or [[live-lock]]s by having the hardware wait a programmable minimum amount of time between each interrupt it generates. Interrupt rate limiting reduces the amount of time spent servicing interrupts, allowing the processor to spend more time doing useful work. Exceeding this time results in a soft (recoverable) or hard (non-recoverable) error.

==See also==
* [[Advanced Programmable Interrupt Controller]] (APIC)
* [[Ethernet flow control]]
* [[IEEE 802.3]] (802.3x PAUSE frames for flow control)
* [[Inter-processor interrupt]] (IPI)
* [[Interrupt]]
* [[Interrupt handler]]
* [[Non-maskable interrupt]] (NMI)
* [[Programmable Interrupt Controller]] (PIC)
* [[Response time (technology)]]
* [[Latency (engineering)]]
* [[Latency (engineering)#Computer hardware and operating systems|Computer hardware and operating system latency]]

==References==
{{reflist|refs=
<ref name="Yiu_2016_Latency">{{cite web |title=A Beginner's Guide on Interrupt Latency - and Interrupt Latency of the Arm Cortex-M processors |author-first=Joseph |author-last=Yiu |date=2016-04-01 |work=Arm Community |url=https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/beginner-guide-on-interrupt-latency-and-interrupt-latency-of-the-arm-cortex-m-processors |access-date=2019-06-15 |url-status=live |archive-url=https://archive.today/20190615044642/https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/beginner-guide-on-interrupt-latency-and-interrupt-latency-of-the-arm-cortex-m-processors |archive-date=15 June 2019 }}</ref>
}}

{{DEFAULTSORT:Interrupt Latency}}
[[Category:Interrupts|Latency]]