Realtime and Linux

The success of Linux in industry would have been inconceivable without realtime features. Realtime is defined here (as in DIN standard 44300) as deterministic behavior. Or in other words - it must be guaranteed that there is a reaction to an external event within a certain time. And the result must be correct.

Basically, there are two approaches to make Linux realtime capable:

the microkernel approach and
the in-kernel approach

In the microkernel approach, all realtime tasks are handled in a separate RTOS (kernel), Linux is scheduled within this RTOS as a low-priority task. Strictly speaking, we do not have to speak of realtime Linux here, but rather of realtime alongside Linux.

The in-kernel approach aims at making Linux intrinsically realtime capable (without an underlying microkernel). The Realtime Preemption Patch originally arose from work by Ingo Molnar and Thomas Gleixner. Especially Thomas Gleixner is the driving force behind the development of PREEMPT_RT today. The Linux Foundation has supported this approach and the complete integration into the mainline kernel in the Realtime Linux Working Group (RTL) for years.

A very good overview of this topic can be found in a talk at the Embedded Linux Conference 2016 and other articles under Linux and Realtime and Embedded Software Engineering.

If you are thinking about implementing Linux as a real-time system for the first time, here is a good place to start: wiki.linuxfoundation.org

The tool cyclictest has become established for testing the realtime behavior of a processor under Linux. If this tool is used together with other programs such as hackbench or pingfloot, a very realistic image of the hardware's behavior under load conditions is obtained.
The following two graphics show the behavior of an ARM processor under Linux V5.x with and without PREEMPT_RT.

The latency to an external event for a kernel without the Preempt-RT patch will be 4665 µsec in the worst case, with the patch it will be reduced to a maximum of 79 µsec in our example. More importantly, the value with Preempt-RT patch is a worst case value, i.e. a value that the CPU will not go beyond.

The long-term measurements of the Open Source Automation Development Lab (OSADL) are certainly worth looking at in this context.

The big advantage of Preempt-RT is that the Linux system itself is not affected. That means the programming model remains the same. You can develop and test exactly as for a common Linux. And also harden and secure the Linux in the same way.
With a dual kernel approach it is different. There you must - if you want to use the time advantages - develop and test everything in the kernel context. And you don't have the Linux subsystems and their drivers available then either.

State-of-the-art Linux kernels allow the isolation of cores in order to be able to execute real-time tasks on them undisturbed. This increases the performance even more. And if that is not enough, you can also isolate a core completely and run bare-metal code on it. Whether this is done in the context of a hypervisor (see also the articles on virtualization and jailhouse as well as realtime and jailhouse) or by configuring the Linux system, we will discuss with you.

Such a solution requires a communication mechanism between bare-metal and Linux application. Linutronix offers you an open source solution for this. So the effort for the implementation of these solutions is simplified significantly.

We are happy to advise you which approach is the best for your needs.