Real-Time Linux vs RTOS: Zephyr, FreeRTOS, PREEMPT_RT

The question of which real-time system to use keeps getting sharper. For years the choice was simple. If you needed tight, predictable timing you reached for a small real-time operating system (RTOS). If you needed Linux, you accepted that Linux was not real-time. That line has moved. As of Linux 6.12, released in November 2024, the PREEMPT_RT real-time work is fully merged into the mainline kernel, and through 2025 and 2026 it has spread to more architectures. At the same time, AI, connectivity, and hard real-time control increasingly land on the same multicore system-on-chip (SoC). This post looks in detail at the three options engineers actually weigh — FreeRTOS, Zephyr, and PREEMPT_RT — works through the real-time Linux vs RTOS trade-off, gives concrete use cases, and closes with where each is likely to head.

FreeRTOS: the minimal kernel

FreeRTOS is a small real-time kernel released under the MIT license, with stewardship passed to Amazon Web Services in 2017. Its design goal is to be minimal and portable: the core is a handful of C files, it runs on more than 40 architectures with 15-plus toolchains, and it is used most widely on Arm Cortex-M microcontrollers. A minimal build occupies roughly 6 to 12 KB of ROM and about 1 KB of RAM.

The scheduler is fixed-priority preemptive. The highest-priority ready task always runs; tasks of equal priority can be time-sliced in round-robin fashion; an idle task runs at the lowest priority; and a tickless idle mode saves power by suppressing the periodic tick when nothing is scheduled. On top of the scheduler, FreeRTOS provides tasks, queues, binary and counting semaphores, mutexes with priority inheritance, recursive mutexes, event groups, direct-to-task notifications, stream and message buffers, and software timers.

Memory handling is deliberate. A system can be built entirely with static allocation, which fixes memory use at build time and removes allocation failures and allocation timing from runtime behaviour. Where dynamic allocation is used, FreeRTOS ships several heap schemes: heap_1 allocates but never frees, heap_3 wraps the standard library malloc and free, heap_4 uses a first-fit algorithm with block coalescence and is the common choice, and heap_5 extends heap_4 across several non-contiguous memory regions.

For larger designs there is FreeRTOS-SMP, which schedules one kernel across several identical cores, and there is memory protection through FreeRTOS-MPU, which runs restricted tasks in unprivileged mode behind an MPU. On ARMv8-M parts such as the Cortex-M23 and Cortex-M33, TrustZone divides execution into secure and non-secure sides. The connectivity story is add-on rather than built in: FreeRTOS-Plus-TCP provides the TCP/IP stack, and the modular AWS IoT libraries — coreMQTT, coreHTTP, coreJSON, plus over-the-air update support — sit on top. Long-term-support (LTS) releases give multi-year maintenance and are also packaged as CMSIS-Packs.

FreeRTOS itself is not safety-certified. Where certification is required, SafeRTOS — a derivative built by WITTENSTEIN high integrity systems from the FreeRTOS functional model — is pre-certified to IEC 61508 SIL 3 and ISO 26262 ASIL D by TÜV SÜD, and supports TrustZone. That gives teams a path from prototype to a regulated product without changing programming model.

Zephyr: the connected RTOS

Zephyr is a larger, full-featured RTOS under the Apache 2.0 license, hosted by the Linux Foundation since 2016 and governed by a broad group of silicon vendors including Nordic, NXP, Intel, STMicroelectronics, and others. Where FreeRTOS is a kernel you build around, Zephyr is closer to a small operating system with batteries included.

The kernel is unified: threads carry priorities, with cooperative threads at negative priorities and preemptible threads at non-negative ones, plus meta-IRQ threads for work that must run ahead of normal threads. It offers mutexes with priority inheritance, semaphores, message queues, pipes, and workqueues, and it can be built with different scheduler implementations depending on the trade-off between speed and memory.

Two things make Zephyr feel familiar to kernel engineers. First, its configuration model is taken from Linux: Kconfig for build-time configuration and devicetree for describing hardware, driven by the West meta-tool and a module system, with toolchains supplied by the Zephyr SDK. It supports Cortex-M, Cortex-R, Cortex-A, RISC-V, Xtensa, ARC, and x86 across more than 600 boards, and includes symmetric multiprocessing. Second, Zephyr has a real user-mode model: on MCUs with an MPU (on Arm, ARC, and x86) it runs threads in user mode with memory domains and partitions, isolates thread stacks, and enforces a system-call boundary, with equivalent support on RISC-V through PMP. Privilege separation of this kind is unusual in an RTOS.

The subsystem list is what sets Zephyr apart for connected products. It ships a Bluetooth Low Energy controller and host, IEEE 802.15.4, Thread, Matter, Wi-Fi, LoRaWAN, CAN, USB device and host, an IPv4/IPv6 network stack with TLS, and filesystems such as littlefs and FAT, alongside sensor, power-management, logging, shell, and settings subsystems. Around the kernel sit the MCUboot secure bootloader, PSA Crypto, a security-response process, and an active functional-safety certification effort, with testing handled by the Twister runner and the native_sim simulator. Zephyr issues rapid feature releases — the 4.x line in 2026 — alongside periodic long-term-support releases.

Real-time Linux: PREEMPT_RT

PREEMPT_RT is not a separate operating system. It is a configuration of the Linux kernel that makes almost all kernel code preemptible, so a high-priority thread can meet a deadline even while the kernel is busy. It reaches bounded latency through a few changes: hardware interrupt handlers run as kernel threads with configurable priorities; most kernel spinlocks (the spinlock_t type) become sleeping locks built on rt_mutex, which support priority inheritance so a low-priority lock holder cannot cause an unbounded delay; and high-resolution timers give fine-grained wakeups. It needs an application-class core with a memory management unit (MMU).

Real-time work on Linux uses the POSIX scheduling policies SCHED_FIFO and SCHED_RR, with priorities from 1 to 99 above all normal tasks. For deadline-driven work there is SCHED_DEADLINE, available since Linux 3.14, which implements earliest-deadline-first scheduling with a constant-bandwidth server. A task declares a runtime, a period, and a deadline through sched_setattr(), and the kernel runs an admission test so the set of deadline tasks stays schedulable. That gives Linux a formal reservation model, not just relative priorities.

The standard way to measure the result is cyclictest from the rt-tests package, which measures the gap between when a high-priority task should wake and when it actually runs:

raghu@techveda.org:~$ sudo cyclictest --mlockall --smp --priority=80 --interval=200 --distance=0
# /dev/cpu_dma_latency set to 0us
T: 0 ( 1520) P:80 I:200 C: 100000 Min:      2 Act:    3 Avg:    4 Max:      58
T: 1 ( 1521) P:80 I:200 C:  99998 Min:      2 Act:    4 Avg:    4 Max:      61

The Max column is what matters: the worst observed latency in microseconds, typically in the tens of microseconds on tuned hardware. Two limits are worth stating plainly. Some kernel paths still use non-preemptible raw_spinlock_t locks and a few interrupts stay non-threaded, so the worst case is larger and less certain than on a small RTOS. And an RTOS bounds latency by construction, while PREEMPT_RT is validated empirically with a tool like cyclictest rather than proven.

Where mainline real-time stands in 2026

The mainline merge was the start of a steady expansion. Linux 6.12 (November 2024) made PREEMPT_RT selectable on x86-64, arm64, and RISC-V. Linux 6.13 (early 2025) added real-time support for LoongArch and introduced a lazy preemption model, which delays the preemption of normal tasks to the next scheduler tick to recover throughput while still preempting real-time tasks immediately. Linux 7.1 (April 2026) added mainline real-time support for 32-bit ARM, the older architecture on many existing embedded SoCs, removing the last widely used out-of-tree patches for it. A small out-of-tree queue remains, including PowerPC, but for the architectures most embedded teams use the real-time kernel is now a configuration option rather than a patch set to maintain.

Real-time Linux vs RTOS: which one?

The real-time Linux vs RTOS decision comes down to how tight and how guaranteed your timing must be, set against how many features you need and how much hardware you can spend. An RTOS on a Cortex-M core has a short, well-understood path from interrupt to task, so its latencies are typically single-digit microseconds and easy to bound, on a device with no MMU and a few kilobytes of RAM. Linux with PREEMPT_RT keeps the full operating system — process isolation, an MMU, drivers, networking, a filesystem — and makes its worst case bounded rather than tiny, on an application-class core. The table below sets the three side by side.

Read the table by column, not by row. FreeRTOS wins where size, cost, and a tiny certified core matter. Zephyr wins where you want one maintained codebase with connectivity and security already present. PREEMPT_RT wins where you already need Linux and want bounded latency on the same chip.

Use cases: matching the tool to the job

• FreeRTOS suits cost- and power-sensitive microcontroller products with hard deadlines and modest connectivity: motor and power controllers, battery-powered sensors, wearables, and appliance control boards. It is also the common choice for the RTOS running on the real-time core of a heterogeneous SoC, and, through SafeRTOS, for regulated products in industrial and automotive systems.
• Zephyr suits connected products that need a maintained protocol stack: Bluetooth, Thread, Matter, and Wi-Fi devices, multiprotocol gateways, and sensor hubs. It suits teams that want to standardise one codebase across many microcontrollers, and products that need userspace isolation and a secure-boot and update story without assembling it from third-party parts.
• PREEMPT_RT suits systems already built on application-class Linux that need bounded latency: industrial controllers and PLCs, robotics running ROS 2, CNC and machine control, professional audio, test and measurement, and telecom data planes.
• A mixed design suits heterogeneous SoCs that carry both core types: Linux, optionally with PREEMPT_RT, on the application cores for interface, networking, and AI, and an RTOS on the real-time cores for the deterministic loop.

Mixed-criticality on one SoC

Modern SoCs increasingly remove the need to choose only one. A single chip carries application cores and real-time cores side by side: NXP i.MX 8M pairs Cortex-A53 cores with a Cortex-M4 or M7; TI Sitara parts such as AM64x combine Cortex-A53 with Cortex-R5F cores; ST STM32MP1 pairs Cortex-A7 with a Cortex-M4; and AMD/Xilinx Zynq UltraScale+ combines Cortex-A53 with Cortex-R5F. This is asymmetric multiprocessing (AMP): Linux runs on the application cores for connectivity, interface, and AI workloads, while an RTOS or bare-metal firmware runs on the real-time cores for the control loop that must never miss a deadline.

The open framework for this pattern is OpenAMP, with three parts: remoteproc for life-cycle management, where Linux loads firmware onto the remote core and starts or stops it; rpmsg for inter-processor messaging; and virtio as the transport underneath. The remoteproc and rpmsg infrastructure has been in the mainline Linux kernel since version 3.4, originally contributed by Texas Instruments. Controlling the second core from Linux is done through sysfs:

raghu@techveda.org:~$ echo rtos_firmware.elf > /sys/class/remoteproc/remoteproc0/firmware
raghu@techveda.org:~$ echo start > /sys/class/remoteproc/remoteproc0/state
raghu@techveda.org:~$ cat /sys/class/remoteproc/remoteproc0/state
running

Mixing tasks of different criticality on shared hardware is also a research field in its own right, dating to Vestal’s 2007 work on scheduling systems with different levels of timing assurance and surveyed since by Burns and Davis. The practical warning from that work is that separate cores do not give separate timing. Even when the control loop has its own core, it still shares the last-level cache and the DRAM controller with Linux, and heavy memory traffic on the application cores can lengthen the worst case on the real-time core. Techniques that address this — cache partitioning and colouring, memory-bandwidth reservation such as MemGuard, and static partitioning hypervisors such as Jailhouse — are worth knowing when the deadlines are strict. Designing this division of work cleanly, including the shared-resource behaviour, is a core skill in our Linux Systems Engineering training.

Where each is heading

FreeRTOS is likely to stay what it is: a minimal, near-ubiquitous kernel. Its growth is not in the scheduler but around it — the AWS IoT library set, long-term-support maintenance, and the certified SafeRTOS path for regulated markets. Symmetric multiprocessing will mature, but the value remains a small and predictable core. The most probable long-term role is the RTOS on the real-time core of heterogeneous SoCs, where its size and determinism are exactly what is wanted.

Zephyr has the clearest momentum among the open RTOSes, and the reason is its backers: most major silicon vendors now support it directly, which means new parts arrive with Zephyr support rather than a proprietary stack. Its direction is broader connectivity, a stronger security and update story, real userspace isolation, and a functional-safety certification path. The likely outcome is that Zephyr keeps displacing in-house and proprietary RTOSes in the mid-to-high-end microcontroller space. The cost of that capability is a larger footprint and a steeper initial setup than FreeRTOS, so the two are more likely to divide the space than for one to remove the other.

PREEMPT_RT has passed its hardest milestone. With the mainline merge complete and architecture coverage still widening, the maintenance burden falls and adoption becomes easier to justify. The work now moves to tooling — latency tracing and validation — to wider architecture support, and to tighter use of SCHED_DEADLINE and real-time-aware frameworks such as ROS 2. It will not replace a hard RTOS where microsecond determinism or formal certification is required. What it will keep doing is absorbing control tasks that once needed a separate processor, because a single Linux core is now often good enough.

The common direction is convergence on one chip. Mixed-criticality on a single SoC is becoming the default system shape rather than a special case, which changes where the hard engineering sits. The difficult questions are moving away from which operating system to use and towards the boundary between them: how the cores are isolated, how they exchange messages, and how shared caches and memory affect timing. The durable advantage for an engineer is the ability to work competently on both sides of that boundary — the Linux side and the RTOS side — rather than only one.

Key takeaways

• FreeRTOS is the minimal, tiny-footprint kernel; Zephyr is the larger, connectivity-rich RTOS with a Linux-style workflow and real userspace isolation; PREEMPT_RT is mainline Linux made preemptible for bounded latency.
• An RTOS bounds latency by construction in single-digit microseconds; PREEMPT_RT gives bounded latency inside a full operating system, typically tens of microseconds, validated with cyclictest.
• Since Linux 6.12 (November 2024), real-time Linux is mainline, and through 2025 and 2026 it reached LoongArch (6.13) and 32-bit ARM (7.1).
• On heterogeneous SoCs the practical answer is both: Linux on the application cores and an RTOS on the real-time cores, joined by OpenAMP, with attention to shared-cache and memory interference.

Further reading

• Real-time Linux: theory of operation and Deadline task scheduling (SCHED_DEADLINE) — kernel.org documentation.
• PREEMPT_RT versions and mainline real-time for 32-bit ARM in Linux 7.1.
• Zephyr Project documentation and FreeRTOS documentation.
• OpenAMP project overview and the Linux remoteproc framework.