Scheduling Latency

Scheduling latency measures the elapsed time from an external event or an interrupt to the start of the execution of the related task. Usually, this would mean, for example, a delay between a timer interrupt and the beginning of executing some periodic task. The scheduling latency is often the single most important value to evaluate when observing a system’s real-time performance. Basically, it combines all sources of latencies into a single variable that is easy to analyze, measure, and compare.

However, for a more detailed analysis, it is often required to individually study the different parts of the scheduling latency. These separate elements are listed in Scheduling Latency Components. The first cause of latency always happens right after the interrupt at the hardware level. Typically, the actual latency caused by hardware is very minimal, just a few clock cycles, but at this stage, additional delay can be experienced if the system interrupts are completely disabled. This can sometimes extend longer periods and is dependent on the currently executing software. The next cause of latency is the immediate interrupt handling routine. Often this part can contain some additional operating system logic, but in general, it is kept as short as possible in real-time systems. After the interrupt is handled, a decision about the next executing task can be done in the scheduler. The scheduler itself is most of the time quite fast, but again at this point, previously running software can cause additional latencies. If the preemption is disabled, the previously executed program is at this point resumed and executed until the preemption is again enabled. Finally, after these steps, the scheduler can schedule a task corresponding to the interrupt by performing a context switch.

With these different parts of latencies, it can be seen that other parts but disabled interrupts and preemption latencies are always fairly constant and predictable. Therefore, these two causes of latencies are significant as they depend on the currently executing program, which means that the delays can extend for a lengthy period. Optimizing and minimizing these two scheduling latency components in the Linux kernel is the most important goal of the PREEMPT_RT patch.