Changes

Generally speaking As known, Linux is not a real-time operating system. As such it can't guarantee that [https://en.wikipedia.org/wiki/Interrupt_latency interrupt latency] is always smaller than a determined limit.

When developing applications base based on embedded platforms, this can cause unacceptable behaviors. For this reason system integrators have to be aware of it and, if necessary, have to implement specific strategies to prevent or limit them.

Numerous solutions exist (see for example [[AN-XELK-001:_Asymmetric_Multiprocessing_.28AMP.29_on_Axel_.E2.80.93_Linux_.2B_FreeRTOS]], [[BRX-WP001:_Real-timeness,_system_integrity_and_TrustZone®_technology_on_AMP_configuration]], https://rt.wiki.kernel.org/index.php/Main_Page). An , however an exhaustive dissertation discussion of these is beyond the scope of this document. InsteadSome practical considerations are illustrated instead, based on real-world cases involving Axel platforms and [Axel_Embedded_Linux_Kit_(XELK) XELK]. ==Disabling interrupts at kernel level==A lot of device drivers exist in the kernel space. Many of them need to temporarily disable interrupts to implement specific hardware-related operations. During the interrupt-disabled time windows, any peripheral could issue an interrupt request anyway. If this happens, associated interrupt service routine execution is delayed (at least) until interrupts are enabled again. As a consequence, in this case the observed interrupt latency is greater than the average one. It is virtually impossible to estimate the upper bound because it is not feasible to explore all the possible execution paths at kernel level. Generally speaking, maximum interrupt latency can be orders of magnitude greater that the average one. ===A real-word case: UART RX FIFO overrun===The following example shows  [Power_management_(Axel)#Interrupt_latency text]