← Previous Lecture | Next Lecture →
- What a real-time operating system actually means, and why “real-time” does not mean “fast”
- How the standard Linux kernel handles preemption, and where it falls short for time-critical work
- What PREEMPT_RT changes inside the kernel — threaded interrupts, rt-mutexes, and sleeping spinlocks
- How PREEMPT_RT evolved from an out-of-tree patch to a mainline kernel feature in Linux 6.12
- Where real-time Linux is used in industry today: robotics, industrial automation, audio, and telecom
If you are starting a free Linux kernel development course journey and keep running into the term PREEMPT_RT, this lecture is where you build the foundation. Real-time Linux is one of the most practical topics in embedded systems, because it sits at the exact point where kernel internals meet real hardware deadlines — motor controllers, audio interfaces, industrial PLCs, and robotics controllers all lean on it.
What Does “Real-Time” Actually Mean?
A common misunderstanding is that a real-time system is simply a fast system. It is not. A real-time system is one that gives a bounded, predictable response time to an event — even if that bound is a few milliseconds. What matters is not average speed, it is the worst-case delay, also called latency. A factory robot arm that responds in 50 microseconds on average but occasionally spikes to 20 milliseconds is not real-time, because that one spike can crash the arm into a wall.
| System Type | Typical Response | Worst-Case Spike | Goal |
|---|---|---|---|
| Standard Linux | Very fast on average | Can spike unpredictably | High throughput |
| PREEMPT_RT Linux | Slightly lower average | Tightly bounded | Predictable worst case |
Why the Standard Linux Kernel Struggles with Determinism
The mainline Linux kernel is built for throughput: get as much total work done as possible. To do that efficiently, several parts of the kernel historically ran with interrupts or preemption disabled for short stretches — spinlocks, some interrupt handlers, and certain critical sections. Each of those stretches is tiny on its own, but they add up into unpredictable pauses called latency spikes. For a web server this is irrelevant. For a CNC controller stepping a motor every millisecond, it is the difference between a clean cut and a ruined workpiece.
What PREEMPT_RT Changes Inside the Kernel
PREEMPT_RT is not a different operating system — it is a configuration of the same Linux kernel that reworks how the kernel handles preemption internally. The three core mechanisms are:
| Mechanism | What Changes | Why It Matters |
|---|---|---|
| Threaded interrupt handlers | Most interrupt service routines run as schedulable kernel threads | A high-priority task can preempt a lower-priority interrupt handler |
| Sleeping spinlocks | Most spinlocks become preemptible, sleep-capable locks | Long lock-held sections no longer block the whole CPU |
| Priority-inheritance rt-mutexes | Locks temporarily boost a low-priority holder’s priority | Prevents priority inversion, where a high-priority task waits on a low-priority one |
Medium-Priority Task —- runs freely, delaying Low-Priority Task —-> system stalls indefinitely
With rt-mutex priority inheritance: Low-Priority Task is boosted to High-Priority until it releases the lock
A Short History: From Out-of-Tree Patch to Mainline Kernel
PREEMPT_RT began in 2005 as a set of community patches maintained outside the main kernel tree, later
stewarded by the Linux Foundation’s Real-Time Linux project. For roughly two decades, using it meant
downloading a separate patch file matched to your exact kernel version and applying it manually — a
process that broke constantly as kernel and patch versions drifted apart. That changed with
Linux kernel 6.12, released in November 2024, when PREEMPT_RT was merged directly into
the mainline kernel for the x86, ARM64, and RISC-V architectures. You no longer need a separate patch file
for these architectures — CONFIG_PREEMPT_RT is simply a configuration option you enable during
make menuconfig.
| Kernel Era | How to Get PREEMPT_RT |
|---|---|
| Before Linux 6.12 | Download a version-matched RT patch and apply it manually to kernel source |
| Linux 6.12 and later (x86, ARM64, RISC-V) | Enable CONFIG_PREEMPT_RT directly from the Preemption Model menu — no patch required |
| 32-bit ARM targets | Still requires the version-matched RT patch, as mainline support is limited to the architectures above |
Prerequisites for This Course Series
- Comfort with basic Linux command-line usage (cd, make, sudo, apt)
- A general idea of what the Linux process scheduler does
- A Raspberry Pi 4 or Raspberry Pi 5 (or any Linux single-board computer) for the hands-on parts of this series
- Basic familiarity with compiling software from source is helpful but not mandatory
Real-World Use Cases for a Real-Time Linux Kernel
| Industry | Why PREEMPT_RT Helps |
|---|---|
| Industrial automation / CNC | Motor step pulses need microsecond-level, jitter-free timing |
| Professional audio | Missed audio buffer deadlines cause audible clicks and dropouts |
| Robotics | Control loops must sample sensors and issue actuator commands on a fixed schedule |
| Telecom / 5G edge | Packet processing deadlines directly affect network quality of service |
Common Mistakes When Learning PREEMPT_RT
- Assuming real-time means faster: it means predictable, not necessarily faster on average.
- Expecting hard real-time guarantees: PREEMPT_RT Linux delivers soft real-time behavior — very high probability of meeting a deadline, not an absolute guarantee like a dedicated RTOS.
- Ignoring hardware: firmware, BIOS/SMI interrupts, and GPU drivers can all introduce latency no kernel configuration can fix.
- Skipping measurement: never assume a kernel is “real-time enough” — always measure latency with a tool such as cyclictest, covered later in this series.
Best Practices Going Into This Series
- Always verify with
uname -aand/sys/kernel/realtimethat PREEMPT_RT is actually active before trusting a build - Keep a non-RT kernel available to boot into as a fallback while experimenting
- Measure before and after any tuning change — never tune blind
- Treat PREEMPT_RT as one piece of a real-time system, not a magic switch; application design and hardware matter just as much
Summary: Key Takeaways
- Real-time means predictable worst-case latency, not raw speed
- PREEMPT_RT reworks kernel locking and interrupt handling to make almost the entire kernel preemptible
- Since Linux 6.12, PREEMPT_RT is a mainline configuration option for x86, ARM64, and RISC-V — no external patch needed on those architectures
- PREEMPT_RT delivers soft real-time behavior, suitable for robotics, audio, industrial control, and telecom workloads
Conclusion
Understanding what PREEMPT_RT actually changes inside the kernel — rather than treating it as a mysterious checkbox — is the foundation for everything else in this free Linux kernel development course. In the next lecture of this series, you will build a real-time-enabled kernel for the Raspberry Pi using the current, mainline-based workflow, configure the right options, and boot into a verified PREEMPT_RT system. From there, the following lecture shows you how to measure that real-time behavior objectively with cyclictest, so you are never guessing about your system’s latency.
Frequently Asked Questions
1. Is PREEMPT_RT a separate operating system from Linux?
No. It is a kernel configuration and set of internal changes applied to the same Linux kernel — not a fork or a different OS.
2. Do I still need to download a patch file for PREEMPT_RT?
Only if you are targeting 32-bit ARM or an older kernel version. For 64-bit x86, ARM64, and RISC-V on kernel 6.12 or later, PREEMPT_RT is built into the mainline source.
3. Does PREEMPT_RT make my system faster?
Not necessarily. Average throughput can be slightly lower due to extra locking overhead; the benefit is a dramatically tighter worst-case latency.
4. Is PREEMPT_RT hard real-time like an RTOS such as VxWorks or QNX?
No. It provides soft real-time behavior — very high reliability, but without the formal deadline guarantees of a dedicated RTOS.
5. Which Raspberry Pi models support PREEMPT_RT?
Raspberry Pi 4 and Raspberry Pi 5 both support building and running a PREEMPT_RT-enabled kernel, which this course series covers in the next lecture.
6. How do I check if PREEMPT_RT is active on a running system?
Run uname -a and look for “PREEMPT_RT” in the output, or check that /sys/kernel/realtime reads 1.
7. What is the difference between PREEMPT_RT and PREEMPT_DYNAMIC?
PREEMPT_DYNAMIC lets you switch preemption models at boot time, but it does not include the rt-mutex and sleeping-spinlock changes that give PREEMPT_RT its latency guarantees.
8. Why do latency spikes happen even on powerful hardware?
Latency spikes usually come from software behavior — long lock-held sections, disabled interrupts, or firmware-level system management interrupts — not from raw CPU power.
Next up: build and boot a real PREEMPT_RT kernel on the Raspberry Pi, step by step.
Next Lecture: Build a PREEMPT_RT Kernel Browse All Free Courses
2 Comments