Interrupt latency: Difference between revisions

Content deleted Content added

Inline

Latest revision as of 15:33, 21 August 2024

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).^[1] 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 controllers, interrupt masking, and the operating system's (OS) interrupt handling methods.^[2]

Background

There is usually a trade-off between interrupt latency, throughput, and processor utilization. Many of the techniques of CPU and 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 schedulability of the system. The Intel APIC architecture is well known for producing a huge amount of interrupt latency jitter.^{[citation needed]}

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 sections 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 systems that need to 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 subroutines. 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 switches and the effective interrupt latency. These include features like:

Minimum jitter through non-interruptible instructions^[1]
Zero wait states for the memory system^[1]
Switchable register banks^[1]
Tail chaining^[1]
Lazy stacking^[1]
Late arrival^[1]
Pop preemption^[1]
Sleep-on-exit feature^[1]

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. For example, most network cards implement transmit and receive ring buffers, 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 storms or live-locks 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.

References

^ ^a ^b ^c ^d ^e ^f ^g ^h ⁱ Yiu, Joseph (2016-04-01). "A Beginner's Guide on Interrupt Latency - and Interrupt Latency of the Arm Cortex-M processors". Arm Community. Archived from the original on 2019-06-15. Retrieved 2019-06-15.
^ Lin, Feng; Ashley, David T.; Burke, Michael J.; Heymann, Michael (1999). "A Hybrid System Solution of the Interrupt Latency Compatibility Problem". SAE Transactions. 108: 2112–2125. ISSN 0096-736X. JSTOR 44733861.

[Yiu_2016_Latency-1] ^ ^a ^b ^c ^d ^e ^f ^g ^h ⁱ Yiu, Joseph (2016-04-01). "A Beginner's Guide on Interrupt Latency - and Interrupt Latency of the Arm Cortex-M processors". Arm Community. Archived from the original on 2019-06-15. Retrieved 2019-06-15.

[2] Lin, Feng; Ashley, David T.; Burke, Michael J.; Heymann, Michael (1999). "A Hybrid System Solution of the Interrupt Latency Compatibility Problem". SAE Transactions. 108: 2112–2125. ISSN 0096-736X. JSTOR 44733861.

[1]

[2]

@@ Line 1: / Line 1: @@
-{{Unreferenced|date=December 2009}}
 {{See also|Latency (engineering)}}
+{{More citations needed|date=June 2019}}
+{{Use dmy dates|date=June 2019|cs1-dates=y}}
-In computing, '''interrupt latency''' is the time that elapses from when an [[interrupt]] is generated to when the source of the interrupt is serviced. 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 mask]]ing, and the [[operating system]]'s (OS) interrupt handling methods.
+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]] (the average rate of successful message delivery over a communication channel), 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.
+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.
+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 an agreed upon 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.
+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:
-There are many methods that hardware may use to increase the interrupt latency that can be tolerated. 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.
+* Minimum jitter through non-interruptible instructions<ref name="Yiu_2016_Latency"/>
-Modern hardware also implements interrupt rate limiting. This helps prevent [[interrupt storm]]s or ''live lock'' 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.
+* 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==
@@ Line 29: / Line 40: @@
 * [[Response time (technology)]]
 * [[Latency (engineering)]]
-* [[Latency_(engineering)#Computer_hardware_and_operating_system_latency|Computer hardware and operating system latency]]
+* [[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}}