PREEMPT_RT for embedded Linux: when does it help meet deadlines?

PREEMPT_RT is worth considering when a Linux device misses a deadline because the operating system takes too long to let an important task run. It can help reduce that delay. Enabling it does not, by itself, guarantee the response time of the whole device or prevent failures. Before committing to a rollout, you need a timing requirement, measurements on the target hardware and an understanding of where the delay occurs.

For someone responsible for the product, the distinction matters. A measurement that finishes late and a screen that is slow to display data already collected may need different fixes. If the brief says only “improve reliability with PREEMPT_RT”, a supplier could improve a system test result while leaving the user's problem unresolved.

Define what needs to happen on time

A timing requirement should identify the start and end of the operation being measured. Is it the time from a sensor signal to a change at an output, from the start of a measurement to its saved result, or from a button press to a response on screen? You can then set the allowed time and the conditions in which it must be met.

Also record what happens if the operation is late. A measurement may need repeating, a result may have to be rejected, or the station may need to stop. The team needs that information to design error handling and decide what to test. Protecting people requires a separate assessment of the complete device; choosing a kernel does not replace that work.

An average response time is not enough if a single missed deadline disrupts the process. In that case, the report should also show the longest delay observed, the number of missed deadlines and the test conditions. The highest measured value describes the sample tested. It is not a guaranteed limit for the device's entire working life.

What PREEMPT_RT changes

The Linux kernel manages programs' access to the processor and hardware. PREEMPT_RT allows more kernel work to be interrupted so a task assigned a higher priority can run sooner. It also changes interrupt handling and locking between tasks. Some kernel paths still cannot be interrupted, as the PREEMPT_RT documentation explains.

PREEMPT_RT has been part of mainline Linux since version 6.12 on supported architectures. It still needs to be enabled in the configuration. Additional RT patches remain under development; the Real-Time Linux project guide covers versions and settings.

When commissioning the work, look for evidence that the chosen configuration works with the drivers and improves how the device performs the required task. Acceptance criteria should describe the device's behaviour, beyond simply confirming that an RT kernel boots.

Where a kernel change is not enough

A device's response involves more than its operating system. Memory access, connections between components and firmware (low-level device software) also matter. The kernel documentation on hardware limitations explains how these can introduce delays.

If the application is waiting for an external service to respond, changing how processor time is allocated will not remove that wait. If the calculation itself takes too long, its execution time needs measuring. PREEMPT_RT may be part of the solution, but it should not replace finding the cause.

Keeping the existing system should remain an option. If it meets the requirements under the agreed conditions, a kernel change needs a specific justification. If a task must keep running while Linux restarts, consider a separate controller. That is a decision about how to divide responsibilities between parts of the device, with its own communication, testing and maintenance costs.

Example: exporting data delays new measurements

Suppose a measurement station collects sensor data, displays results and lets an operator export earlier measurements. During an export, some new measurements finish after their deadline and have to be repeated. This is a hypothetical example, not a customer deployment or a PREEMPT_RT benchmark.

The team first checks whether the measurement task gets processor time too late or stalls later, while reading the sensor, calculating a result or saving data. Separating report writing from the measurement operation may help. Trying RT is justified when the diagnosis points to delays that this change could affect.

Acceptance testing covers simultaneous measurement and export on the target device. Alongside timing, it needs to check that results are correct and complete, and that the operator can still use the device. Faster results achieved by dropping data do not solve the problem. A slower export may be acceptable if the business explicitly agrees to that trade-off and the user can see its progress.

What evidence to request before rollout

The cyclictest tool helps assess delays before test tasks resume running. It does not measure the complete path from a sensor to a finished device operation. The team can also use rtla timerlat to investigate delays and save a trace when a chosen threshold is exceeded. These results complement application testing.

Ask for a comparison of the existing and proposed versions using the same scenarios. The report should identify the hardware, software versions, configuration, workload and test duration. Include operations that the device actually performs at the same time, along with its operating conditions. Also check what happens when a deadline is missed: is the error visible, and could an incomplete result be passed on as valid?

The cost of implementation includes diagnosis, any application or driver changes, a test setup and checks on future updates. Agree who will maintain the chosen version, repeat tests after changes and prepare a way back to the previous version if an update makes the device perform worse.

A useful brief therefore starts with a specific operation and an acceptance condition: “Measurements must finish within the agreed time even during an export, and any missed deadline must be detected.” That gives you a basis for deciding whether PREEMPT_RT solves the product's problem and what work is actually needed.