Real-time Linux options compared: PREEMPT_RT, Xenomai, RTAI, and commercial

Stock Linux is not a real-time operating system. It’s tuned for throughput and fairness, not for guaranteeing that a task runs within a bounded deadline every single time. For a lot of Embedded (Real-Time) Linux work — motion control, data acquisition, industrial I/O — that guarantee is exactly what you need.

There are three practical routes to get it. Here’s how they actually differ, and when each one is the right call.

Two philosophies first

Every option falls into one of two camps:

• Single-kernel — make the Linux kernel itself preemptible enough to meet deadlines. Your code stays a normal Linux application/driver. This is PREEMPT_RT (and the commercial distros built on it).
• Co-kernel (dual-kernel) — run a small, hard real-time core alongside Linux that handles time-critical work with priority over Linux entirely. Linux becomes the “idle task” of the real-time core. This is Xenomai and RTAI.

The single-kernel route is simpler and more maintainable. The co-kernel route historically wins on worst-case latency, at the cost of complexity. That tension is the whole story.

PREEMPT_RT — now the default answer

PREEMPT_RT converts most of the kernel’s non-preemptible sections into preemptible ones: it makes spinlocks sleepable, moves interrupt handlers into threads you can prioritise, and tightens the paths that used to cause unbounded latency. Your application uses ordinary POSIX real-time facilities (SCHED_FIFO, priorities, mlockall) — no special API.

The big news: after roughly two decades as an out-of-tree patch, PREEMPT_RT was merged into the mainline Linux kernel in 6.12 (September 2024), for arm64, riscv and x86. The last blocker was the printk rework. Some optimisations still live outside mainline, but the core is now upstream — which means far less patch maintenance going forward.

Pros

• Standard programming model — normal Linux drivers and apps.
• Mainline: no out-of-tree kernel patch to track (huge maintenance win).
• Broad hardware and driver support — it’s just Linux.

Cons

• Soft/firm real-time: excellent average and good worst-case latency, but not the absolute lowest bounded jitter a co-kernel can hit.
• Some throughput cost.
• Still requires tuning (IRQ affinity, isolation, priorities) and measurement.

Pick it when: you need reliable determinism in the tens-of-microseconds range, and you value maintainability and mainline support — which is most projects today.

Xenomai — the co-kernel for the hard cases

Xenomai runs a dedicated real-time core beside Linux. In Xenomai 3 you choose:

• Cobalt — the true dual-kernel. A small real-time co-kernel handles interrupts and scheduling with priority over Linux, delivering very low, tightly bounded latency. Real-time code talks to Xenomai’s API and uses RTDM drivers.
• Mercury — a single-kernel mode that provides the same Xenomai API but relies on an underlying PREEMPT_RT kernel for the timing. Useful for keeping one codebase across both models.

Xenomai 4 is the newer direction, built on the EVL core and the Dovetail interrupt pipeline, aimed at better scalability and closer alignment with upstream Linux.

Pros

• Best-in-class, tightly bounded worst-case latency (Cobalt).
• Real-time behaviour is largely insulated from what Linux is doing.

Cons

• You program to the Xenomai API, not plain POSIX — and you need RTDM drivers for your peripherals, which limits hardware choices.
• Patched kernel + interrupt pipeline to track against kernel updates.
• More moving parts to build, debug and maintain.

Pick it when: you have genuinely hard requirements — sub-10-microsecond bounded worst case, tight control loops — that PREEMPT_RT can’t guarantee on your hardware, and you can absorb the complexity.

RTAI — powerful, but legacy

RTAI (from Politecnico di Milano/DIAPM) is the other classic co-kernel, and historically posted some of the lowest latencies of any option. But be clear-eyed about its state: it is community-maintained with limited active development, its ARM support is effectively obsolete, and it tracks specific older kernels.

Pros

• Historically excellent hard real-time latency on x86.

Cons

• Aging, thin maintenance; risky for new products.
• Tied to specific kernels; ARM largely unsupported.
• Smallest community of the three.

Pick it when: you’re maintaining an existing RTAI system. For anything greenfield, PREEMPT_RT or Xenomai is the safer bet.

Commercial real-time Linux

If you’d rather buy support, long-term maintenance, and help with certification, several vendors ship supported real-time Linux — almost all now built on PREEMPT_RT:

• Red Hat Enterprise Linux for Real Time — a supported kernel-rt (PREEMPT_RT) platform with long-term maintenance. RHEL 10 (2025) ships on the 6.12 line that carries mainline PREEMPT_RT.
• Real-time Ubuntu — Canonical’s PREEMPT_RT kernel, generally available since 2023 via Ubuntu Pro, covering x86 and Arm.
• Wind River Linux — a long-standing commercial embedded Linux with real-time and safety-certification offerings.

Pros: vendor support, tested LTS kernels, security maintenance, and a partner for functional-safety certification. Cons: subscription cost, and you’re on the vendor’s kernel cadence.

Pick it when: downtime or a missed deadline is expensive, you need a support SLA, or you’re heading for safety certification.

How to choose — the short version

One rule that applies to all of them: latency is a property of your hardware and tuning, not just your choice of patch. The same SoC can be great or terrible depending on BIOS/firmware, SMIs, IRQ routing, CPU isolation and power management. Whatever you pick, you have to measure worst-case latency under realistic load (for example with cyclictest) and prove it — a number on a datasheet is not a guarantee on your board.

Deciding which real-time approach fits your product — or chasing latency spikes you can’t explain? Embedded (Real-Time) Linux work is exactly what we do.

Sources: Linux kernel 6.12 PREEMPT_RT merge (2024); Xenomai 3/4 project documentation; RTAI project status; Red Hat Enterprise Linux for Real Time; Canonical Real-time Ubuntu.