Linux as RTOS

Most of the telecommunication and data-communication products use Real Time Operating Systems (RTOS). Application of a RTOS is called embedded software. Let's discuss some basic definitions and classification of RTOS and how Linux does it.

Since Linux is an open-source operating system with strong ability to support multiple processors, including MIPS, x86, PowerPC, its becoming more popular with the embedded software developers as RTOS. Because of Linux open-source nature, its constantly evolving. In this article, the standard Linux is analyzed.

What's an RTOS

An RTOS has ability to respond to an external event within a deterministic time. The performance of the real time is measured by the RTOS customers based on the information provided by the RTOS vendors to analyze the execution times for interrupts and any system tasks that are higher priority than the customer's tasks.
The "kernel" of a RTOS provides an "abstraction layer" that hides the hardware details of the processor (or set of processors) from application software upon which it runs.

Hard real-time applications have a very specific deadline. That is the RTOS must respond to application within a specific time, otherwise an unacceptable result occurs. Something blows up, something crashes, some operation fails, someone dies. Soft real-time applications usually must satisfy a deadline, but if a certain number of deadlines are missed by just a little bit, the system may still be considered to be operating acceptably.

Real Time kernel services: The kernel service includes: Task Scheduling, Intertask communication and synchronization, Timer, Dynamic Memory Allocation, and Device I/O Supervisor.

• Task Scheduling services include the ability to launch tasks and assign priorities to them.


• Intertask communication and synchronization services make it possible for tasks to pass information from one to another, without danger of damaging the information. That is while a piece of information is being updated by a task, another task cannot make changes to the same piece of information. This is called synchronization. RTOSs provide semaphore or mutex mechanism, event-flag or signal for synchronization.


• Timer - Since many embedded systems have stringent timing requirements, most RTOS kernels also provide some basic Timer services, such as task delays and time-outs.


• Dynamic Memory Allocation - Many RTOS kernels provide Dynamic Memory Allocation services. This category of services allows tasks to "borrow" chunks of RAM memory for temporary use in application software. Often these chunks of memory are then passed from task to task, as a means of quickly communicating large amounts of data between tasks. To avoid the delay associated with memory fragmentation and defragmentation , the Real-time operating systems offer non-fragmenting memory allocation techniques. For example, the "Pools" memory allocation mechanism rather than conventional "heap" memory allocation mechanism allows application software to allocate chunks of memory in different buffer sizes per pool. Typical buffer sizes are 31, 63, 127, 255, 511, 1023, 4095, and 65535 bytes. "Pools" totally avoid external memory fragmentation, by not permitting a buffer that is returned to the pool to be broken into smaller buffers in the future. Instead, when a buffer is returned to the pool, it is put onto a "free buffer list" of buffers of its own size that are available for future re-use at their original buffer size.


• Device I/O Supervisor - These services, if available, provide a uniform framework for organizing and accessing the many hardware device drivers that are typical of an embedded system.

Other high-level components, such as as file system organization, network communication, network management, database management, and user-interface graphics are optionally added to the operating systems. These services, although much larger and much more complex than the RTOS kernel, rely on the presence of the RTOS kernel and take advantage of its basic services. In order to keep the memory consumption to a minimum, each of these add-on components is included in an embedded system only if its services are needed for implementing the embedded application.

Linux as RTOS

In general, Linux is designed for performance-limited applications, but it is not well designed for deterministic response. In a sense, Linux is not considered to be a real-time operating system because it cannot guarantee deterministic performance. Study shows that the Linux kernel, in a relatively easily constrained environment, may be capable of worst-case response times of about 50ms, with the average being just a few milliseconds. Many real-time applications require response time significantly below 1ms and within µs.

There are two main reasons for Linux poor performance on uniprocessor systems. 1) Linux kernel disables interrupts, 2) Linux kernel is not preemptible. Needless to say Linux is certainly multithreaded, supports thread priorities and provides predictable thread-synchronization mechanisms.

If interrupts are disabled, the system is not capable of responding to an incoming interrupt. The longer that interrupts are delayed, the longer the expected delay for an application's response to an interrupt. The lack of kernel preemptibility means that the kernel does not preempt itself, such as in a system call for a lower-priority process, in order to switch to a higher-priority process that has just been awakened. This may cause significant delay.

On a multi-processor systems, the Linux performance can be even worse, since the kernel also employs locks and semaphores that will cause more delays.

Using Linux in Real-Time application?

A real-time application may call almost all 208 system calls in Linux kernel, indirectly through library routines. Contention for resources, such as synchronization primitives, main memory, the CPU, a bus, the CPU cache and interrupt handling can considerably slow down an application running on Linux from its best case.

Some tricks that real-time applications have developed to improve the Linux kernel response time follows: give themselves a high priority; lock themselves in memory (and don't grow their memory usage); use lock-free communication whenever possible; use cache memory wisely; avoid nondeterministic I/O (e.g., sockets) and execute within a suitably constrained system including limiting hardware interrupts, limiting the number of processes, curtailing system call use by other processes and avoiding kernel problem areas, e.g., don't run hdparm.

Improvements to Linux Kernel

Some efforts has taken place to improve the kernel preemptibility which has resulted kernel to respond faster to applications without any need to modify the application code. The preemptible Linux kernel patch that was originally introduced by MontaVista Software and subsequently championed by Robert Love was merged by Linus Torvalds into the main linux development-kernel tree, beginning version v2.5.4-pre6, thus adding a far greater degree of real-time responsiveness to the standard Linux kernel.