Why Linux Is Not a Real-Time Operating System

Many people assume that because Linux provides real‑time scheduling policies such as SCHED_FIFO and SCHED_RR, it can serve as a real‑time operating system. The article explains why this assumption is incorrect.

Real‑time systems are defined by predictability: the response time to an event must have a known upper bound. For example, a real‑time system might guarantee that handling an interrupt never exceeds 100 µs, whereas a general‑purpose system could take anywhere from 10 µs to several milliseconds.

Linux’s design goals focus on high throughput, high concurrency, and good average performance. To achieve this, the kernel employs complex scheduling algorithms, dynamic memory management, caching, and interrupt coalescing. These optimizations improve average case performance but sacrifice the deterministic latency required for hard real‑time.

The default Linux scheduler, the Completely Fair Scheduler (CFS), aims to share CPU time fairly among all tasks. Fairness conflicts with real‑time requirements, where high‑priority tasks must run immediately regardless of other tasks’ states. Consequently, even when a task is set to SCHED_FIFO, Linux cannot guarantee execution within a strict deadline because the kernel is not fully preemptible.

Non‑preemptible sections in the kernel, such as critical sections protected by locks, cannot be interrupted. When the kernel holds such a lock, a high‑priority real‑time task must wait, introducing unpredictable latency.

An automotive example illustrates the problem: a control module scheduled every 10 ms using SCHED_FIFO occasionally exhibited delays of 15–20 ms. Investigation revealed that during network‑interrupt handling the kernel disabled preemption, forcing the real‑time task to wait.

The PREEMPT_RT patch addresses these issues by making the kernel fully preemptible, converting interrupt handling to kernel threads, and replacing spinlocks with sleeping mutexes. These changes dramatically reduce maximum latency; measurements show a vanilla kernel can have millisecond‑scale worst‑case latency, while a PREEMPT_RT‑patched kernel can achieve latencies under 100 µs.

However, even with PREEMPT_RT, Linux cannot be considered a hard real‑time system. Factors such as virtual memory page faults and dynamic memory allocation remain sources of nondeterministic delay. The article recommends using mlock to pin real‑time task memory, pre‑allocating memory pools to avoid malloc / free in time‑critical paths, and isolating CPUs to keep real‑time tasks away from interrupt handling.

In summary, Linux’s core design does not target real‑time guarantees. With PREEMPT_RT and careful system tuning, it can meet soft real‑time requirements suitable for many embedded applications, but scenarios demanding strict microsecond‑level guarantees still rely on dedicated real‑time operating systems such as VxWorks, QNX, or FreeRTOS.