Real-time Linux is officially part of the kernel

Original Article ↗ Hacker News Discussion ↗

Scope of the Change

  • PREEMPT_RT is now a configurable option in mainline Linux, rather than an out-of-tree patchset or separate RT hypervisor.
  • Much of the work centered on making kernel subsystems and locking more preemptible; printk and interrupt handling were recurring technical points.
  • The RT patchset is now significantly smaller; some pieces (e.g., new printk paths in drivers) still need adoption.

What “Real-Time” Means Here

  • Emphasis is on bounded worst‑case latency and predictability, not raw speed.
  • RT Linux aims to ensure that high‑priority tasks can preempt others quickly and run to completion within deadlines.
  • For strict hard real‑time and safety‑critical uses (e.g., car brakes, avionics), several commenters argue Linux—even with PREEMPT_RT—is still not ideal; specialized RTOSes or formally verified kernels (like seL4) are preferred.

Practical Use Cases and Experiences

  • CNC and industrial control: LinuxCNC and similar systems rely heavily on RT; merge is seen as a major simplification for builds and deployment.
  • Audio and music: Users report dramatic reductions in audio latency and dropouts, enabling low‑latency instrument setups and complex audio chains while the system is heavily loaded.
  • Robotics, SDR, and embedded control: RT kernels reportedly provide microsecond‑scale jitter, making things like software-defined radio and flight control more robust under load.

Programming and System Design Practices

  • Real‑time coding focuses on predictable execution: avoiding dynamic allocation, blocking syscalls, and complex variable‑time algorithms in RT threads.
  • Designs often use periodic loops/state machines and offline scheduling or strict priorities.
  • On MCUs, caches and advanced CPU features are sometimes disabled to avoid jitter; on Linux/x86 this is harder and interacts with power management, SMM, drivers, and multicore effects.

Desktop Impact and Trade‑offs

  • Some claim little desktop benefit; others report noticeably better responsiveness and far more reliable low‑latency audio.
  • Consensus: throughput is slightly lower and scalability somewhat reduced due to extra locking and scheduling work, but often not visible on typical desktops.
  • Misconfigured priorities or buggy drivers can still cause latency spikes; RT is not a magic fix, just a better foundation.