The Many Challenges of Real-Time Linux

Real-time Linux is a type of mainline Linux that is PREEMPT_RT enabled. When embedded projects require real-time operating systems, developers often opt for a PREEMPT_RT kernel patch that turns Linux into a real-time system. However, most real-time requirements among embedded projects can be fulfilled without using a real-time operating system. This is because a real-time system is a system that executes commands within given time frames, and depending on embedded projects’ real-time requirements, any operating system may be able to fulfil the real-time operation duty. So, when should developers utilize the real-time patch?

When and how real-time Linux is used by Embedded Developers

When to use real-time Linux depends on individual developer preferences and system requirements. For instance, ATMs do not require an RTOS because they can operate on non-buggy codes that allow them to form realistic deadlines. However, embedded devices that respond to “must have” deadlines may require the PREEMPT_RT patch. This is because PREEMPT_RT offers faster response periods and gets rid of unbounded latencies. Unbounded latencies occur where the magnitude of delays that may occur depends on the embedded system’s situation.

In regards to soft and hard real-time systems, PREEMPT_RT is designed to harden Linux. Though this may not be mathematically proven, unbounded latencies in PREEMPT_RT are considered bugs that ought to be fixed immediately because they trigger the occurrence of the non-deterministic behavior. Hence, PREEMPT_RT strives to make Linux as hard as possible. In most cases, mainline Linux executes commands promptly, but outliners may occur and cause large unexpected delays. A desktop whose PREEMPT_RT kernel is properly installed offers smoother operation.

The PREEMPT_RT is installed and run prior to being used in embedded development. It is preferred over other real-time Linux applications because it directly makes Linux real-time while other real-time applications create a microkernel that operates as a hypervisor while Linux runs as its task. This means that all real-time tasks should be altered to communicate with the hypervisor. On the other hand, when PREEMPT_RT interrupts run as threads, you can adjust the interrupts’ priorities and allow user space tasks to run at higher priorities than interrupts. Additionally, with interrupts running as threads, you can prioritize interrupt handlers even where there is no hardware support.

Real-time Linux Challenges

The biggest challenge with real-time Linux is the conversion of spin_locks to mutexes because it changes some spin_lock side effects assumptions. For instance, some kernel code assumes the disabling of pre-emption. PREEMPT_RT on embedded development is tested on ARM, PowerPC and x86 regularly. Nonetheless, the real-time patch is more accepted and in use today compared to five years ago, when some of its parts were installed into the kernel through Trojan horses. Note that Linux quality when in use on large scale SMP machinery is highly dependent on the real-time patch. It is therefore more of an asset to Linux because it offers a clean code base.

Real-time also tends to be highly sensitive to bugs compared to the mainline kernel. As a result, PREEMP_RT triggers bugs in the mainline reliably. A bug that the real-time patch triggers in hours can take months to trigger in a normal Linux setting. That’s why Linux thrives under the real-time patch.