Real-Time Linux Explained
Real-time work is about meeting deadlines. Average speed is useful, but it does not describe the longest delay a control task may experience.
Describe the deadline first
A periodic task has a release time, an execution budget and a deadline. For a loop scheduled every millisecond, it matters whether the complete operation finishes on time, not simply whether its average computation takes less than a millisecond. The effect of a missed deadline depends on the controller and system design.
Distinguish scheduling latency, task execution time, communication delay and actuator response. A measurement of one does not certify the others. A faster processor can still produce unsuitable timing when software queues, drivers or competing work introduce delays.
What PREEMPT_RT changes
PREEMPT_RT makes more kernel execution preemptible through changes to locking and interrupt handling. Many locks use priority-inheritance-aware sleeping implementations, and much interrupt work can run in schedulable threads. Some low-level critical paths remain non-preemptible. These mechanisms can reduce the delay before a high-priority task executes, but they do not establish a universal bound for every machine.
Measure before tuning
The cyclictest tool measures the difference between a scheduled wake-up time and the actual wake-up time. Use a dedicated test machine and read the tool's documentation before choosing real-time priorities. Priority changes can interfere with other work; examples are not instructions to reconfigure an unrelated production server.
Record the kernel configuration, CPU, firmware, scheduler settings and workload. Observe an idle case and representative competing activity. Keep the distribution of latency and the largest observed value, together with the test duration. A maximum from a finite run is an observation, not proof that a larger delay is impossible.
Look beyond the scheduler
Check memory behavior, interrupt placement and the communication path. Unplanned page faults, blocking I/O and shared-resource contention can disturb a task even when scheduler latency looks small. Memory locking and preallocation may be part of an application design, but they require resource limits, error handling and testing.
A useful investigation changes one variable at a time. Begin with a repeatable baseline, keep a record of each adjustment and retain a way to restore the previous configuration. Avoid copying CPU-isolation or priority settings from a different hardware layout without understanding the dependencies.
Common practical mistakes
- Dynamic memory allocation in cyclic loops: Calling
malloc,free, or dynamically growing containers inside a 1 kHz motor loop triggers kernel page allocations and unbounded latency. Pre-allocate all buffers and callmlockall(MCL_CURRENT | MCL_FUTURE)at process startup. - Ignoring System Management Interrupts (SMI): On x86 PC architectures, hardware motherboard firmware can hijack the CPU for thermal or power management via SMIs, freezing execution for 100+ μs regardless of RT kernel patches.
- Running RT threads on Core 0: CPU core 0 typically handles default hardware interrupts and timer routines. Always isolate specific CPU cores using
isolcpusand pin real-time tasks usingpthread_setaffinity_np. - Unbounded priority inversion: Using standard non-RT mutexes across threads of differing priorities allows a medium-priority background task to block a high-priority motion thread indefinitely.
No safety certification. This note is an introduction. Neither the illustrative waveform nor an example latency value demonstrates that a robot is safe or that a hard deadline is guaranteed. Safety-critical control needs system-specific engineering and validation.