Introduction to Real-Time Operating Systems and Realtime Linux

Ulas Turan July 2, 2011

1

Introduction

A system that runs with operational deadlines contains real-time constraints. Real-time systems arise in many fields such as telecommunications, manufacturing, military and defense. In a non-real time system, the main goal is to utilize the maximum available throughput. Fast-response and high performance is the concern; however, it is not critical if the system misses some of its deadlines during run-time. On the other hand, a real-time system may cause a failure when it misses a deadline. The airbag system in the cars is a simple example of a real-time computing system.

2

Real-Time Operating System Fundamentals

Real-time operating system (RTOS) serves applications within some guaranteed time boundaries. It builds a framework for the real-time processes to meet timing constraints. RTOS must provide deterministic responses to unpredictable concurrent events. An application that runs on a RTOS does not necessarily obey the real-time constraints. Meeting the deadlines and response times needs a careful design. The RTOS and the processes should run in a harmony. Designer should know the limits of the RTOS and also be aware of the running real-time processes during the system operation. Embedded processor are generally the target platform to run RTOS, however, it is possible to run some RTOSs on desktop processors such as Intel x86 family. RTOS share common properties with standard operating systems, however several characteristics make the distinction. Essentially, it provides the desired abstraction between the hardware and upper level application layer. RTOSs offer similar services as the general-usage operating systems: • File Systems • Networking • Device Drivers 1

• Secutity This infrastructure is almost the same in both RTOS and every day-use operating systems. These features will not be discussed in the scope of this document. What makes the RTOS special is the difference in the essentials of the operating system that causes the unbounded latencies. RTOS has significantly different approach in the following services: • Process Management • Interrupt Handling • Memory Management Before going into the details of the RTOS, it is intuitive to cover RTOS classification. RTOSs are divided into two sub-categories according to their reaction for real-time constraints. Soft-RTOSs are designed to meet deadlines most of the time during operation and the processing performance is generally an important concern for this type. Percentage of missed deadlines is a possible metric for benchmarking. Hard-RTOS specifies deterministic response times and holds these promises on the long run. Context switching time and interrupt latencies are among the performance metrics for Hard-RTOS. If missing any deadlines causes a system to fail, then hard-real time OS will definitely be the choice.

2.1

Process Management

Central processing unit (CPU) is able to perform one instruction of any process at a time. In modern operating systems, such as Linux and Microsoft Windows, several processes may reside in memory and wait for the CPU to perform their instructions. CPU serves those processes at some intervals determined by the operating system. In this way, multiple processes may be executed at a given time interval. Operating system that is capable of concurrently executing several processes is known as multi-tasking operating systems. It enhances the efficiency over the single-tasking operating systems in which CPU may lay idle considerable amount of time. Figure 1 illustrates the process states and transitions in a multitasking RTOS.

2

Figure 1: Process States in RTOS When a user creates and starts a process, it will initially be in the Ready state. Process in the Ready state resides on a linked list so-called Ready-List as seen in Figure 2. It orders multiple processes that are waiting to execute their instructions. in figure 3 is that Running state have toCPU executes whole list in order list as shown A process is at the kernel may when go through the its instruction. Waiting processpriorityblocked This actually happens every time a high priority task to insert a low stays TCB. until it receives a timer interrupt, a message or a signal. After anypriority interrupts causesare only used to wake purpose of illustration. preempts a lower of the task. Linked lists the process here for up, it immediately enters into actually better techniques to insert and remove TCBs in ROM inactively. There are the Ready List. Process in Dormant state resides from a list instead of using linked lists. This is, however, a topic that is beyond the scope of this paper.
Highest priority Ready List Lowest priority 0

TCB

TCB

TCB

TCB

TCB

Figure Figure 3 List 2: Ready

EVENT MANAGEMENT 2.2 Scheduling
In general-purpose operating systems, processes are executed equally. an event The kernel provides services to allow a task to suspend execution until That means a The mostin the Running state grasps the is the semaphore. time-slice. Itis occurs. process common type of event to wait for CPU for a fixed A semaphore may end either control access to a shared resourceit (mutual exclusion), signal the used to up its execution before time-slice when finishes up its instructions or needs another event or resource to continue. The scheduler is generally impleoccurrence of an system allow two tasks to synchronize their activities. A semaphore generally consist of a value (an unsigned 16-bits variable) This type of scheduling mented with a round-robin algorithm with time-slice. and a waiting list (see figure 4). may cause the real-time processes to miss their deadlines for the sake of fairness. RTOS resolves this problem by introducing the PREEMPTION Policy to Semaphore Tasks waiting on semaphore
Value == 0 List Pointer Highest priority

3

Lowest priority 0

TCB

TCB

TCB

Figure 4

the scheduler. In this case, scheduler may preempt lower-priority task in the Running state and put a higher priority one instead. RTOS continuously polls the Ready List to check if there is a higher priority task waiting in the queue. It is against the fairness principle of the general-purpose operating systems and it may cause degradation in the overall processing power of the system. There are several scheduling algorithms available for RTOS such as Liu and Layland Rate-Monotonic scheduling algorithm and Earliest Deadline Priority (EDF) algorithm [1]. Rate-monotonic scheduling is the common choice for preemptive scheduling. This scheduling requires processes to have static priorities based on the execution length. EDF algorithm dynamically assigns process priorities according to the deadlines. 2.2.1 Context Switching

It refers to the series of actions that happen when the computational resources transfers from Running process to the one in Ready List. In multitasking operating systems, each process has a special data structure called Process Control Block (PCB). As the Running process changes its state, it immediately saves its registers to the PCB. It allows the process to restore its former execution state when it owns CPU once again. Context switching time is an important concern for RTOS as it happens more than often. This timeout depends on operating system PCB data structure as well as the processor architecture.

2.3

Interprocess Communication

Processes running on the multitasking system may need to communicate with each other. Data structures within the operating system should be made available to only one process at any time. Otherwise, processes may end up using them inconsistently. Operating system maintains the consistency by allowing just one process to reach the data. Disabling interrupts temporarily or using binary semaphores are two possible approaches for the resolution. In the first method, a process disables all system interrupts during its execution. Therefore, it can safely reach the data structure without a concern as nothing can interfere its execution. One should never disable interrupts (even temporarily) without considering the interrupt latency of the RTOS. Long execution times with the masked interrupts will add-up to the worst-case latency because RTOS looses its control over the processes. It is usage is thus limited to tasks that have few instructions to complete. Using binary semaphore namely mutex is more secure but costly alternative. When a process needs resources in the critical section it informs the RTOS. Operating system will continue to have the control while processes are in the critical section, which means that RTOS may continue to provide real-time behavior. As the processes notify the RTOS, it takes more processing power to retain the critical sections in this way. While using mutexes, lower priority processes may lock the resources and higher priority process that needs those resources will not be able to continue its execution. In this situation, when a medium priority task starts it will preempt low priority task. In the end,

4

medium priority task will run before the high priority task. This situation is called priority-inversion and should be avoided in RTOS. It can be accomplished with priority-inheritance; such that, lower priority process assumes the priority of higher priority process and continues its execution. Whenever it releases resources of the higher priority process it restores its original priority level.

2.4

Interrupt Handling

Interrupt Request (IRQ) notifies the operating system for occurrences of external events. If the interrupts are not disabled, CPU polls for IRQ at the end of each instruction. When there is an IRQ available, processor terminates its current execution and identifies received interrupt signal. Then processor starts to service the interrupt. Operating systems treats incoming interrupts with a corresponding routine called Interrupt Service Routine (ISR). IRQ has the higher priority than the highest priority process. Therefore RTOS has to make ISR as short as possible and return back to the execution of processes. Interrupt latency is the elapsed time after receiving an interrupt signal until the start of the corresponding ISR.

2.5

Memory Management

Operating systems provide memory management service to control the portions of physical memory required by the processes. Memory management unit allocates programs requested memory and frees up unused portions. Generalpurpose operating systems provide the separation of process memory blocks by using virtual memory. Virtual memory is an abstraction layer between the physical memory and the process. It maps data structure used by processes to the locations in the physical memory. A process reaches its data through virtual memory. This isolation allows memory protection. Virtual memory has a demand paging utility. Demand paging dynamically exchanges the memory blocks between physical memory and the main storage unit. It stores the recently used memory blocks on the physical memory, whereas the formerly used portions are transferred to the storage unit. Demand paging introduces are not suitable for as it produces and overhead while reading and writing to the storage unit. This procedure will suspend the process for an indefinite amount of time. Although virtual memory builds the proper abstraction to achieve memory security, it should be avoided in RTOS.

2.6

Measuring the Real-Time Performance

In real-time multi tasking systems, several concurrent processes run in the same context. As the load on the system increases it becomes harder to satisfy the required deadlines. A non-real time system may have better throughput under idle condition; yet, hard-real time system continues to satisfy the requirements even if the system load increases. Thus it is not a practical way to obtain

5

measurements under no load situations for a real-time behavior. The most important aspect of a real-time system is its predictability not the performance. Real-time system design should address worst-case situations and careful insight should be made for those assumptions. Real-time behavior may refer to different aspects of RTOS. There is more than single method to measure the real-time performance. Interrupt latency and context switching time are the most common ones indeed.

3

Choosing the Right Real-Time Operating System

Today there are several popular proprietary RTOSs such as: Windriver VxWorks, Greenhills Integrity, QNX Neutrino. Those firms provide reliable RTOSs, which are developed with continuous analyses and tests. Their products offer a complete operating-system environment besides real-time scheduler. In addition, they often specialize their software for the customers specifications to meet the expected performance criteria. It involves a continuous integration of the customer with the RTOS companies. Generally, end users work with supplied Integrated Development Environment (IDE) while developing their projects for the target platforms. Those IDEs contain cross-compilers to generate binaries that will run on the target hardware with the RTOS. Associated costs are not affordable by many of the developers. Startup costs range from $10.000 to $50.000 and it adds up with royalties due to the every copy shipped to the customer [2]. In any of those RTOSs the basic kernel operation will be similar. Memory requirements, supported processors, and additional software modules (networking protocol stacks, device drivers, flash file systems) makes the difference. Realtime Linux is a license free RTOS which is developed on mainline Linux Kernel. Ingo Molnar and Thomas Gleixner have great contribution for the existence of Realtime Linux. Currently, Open Source Automation Development Lab (OSADL) supports Realtime Linux; they hold conferences, measure and monitor the performance of latest kernel with a variety of hardware architectures and assist open source developers online [3].

4
4.1

Realtime Linux Operating System
Basics Of Linux Operating System

Linux operating system is free and open-source software that is widely used today in many platforms including personal computers, servers, mobile devices, and game consoles. It is distributed with GNU General public license that makes it so popular and is the main reason behind its rapid evolution in the past decades. GNU General Public License allows Linux source code to be freely used, modified and distributed with anyone either commercial or not [4]. Like in many modern operating systems, Linux separates virtual memory into

6

Kernel Space and User Space. Core operating system functionalities are found in the Linux Kernel. It consists of a task manager, a file system manager, and the hardware access manager [5]. Some drivers to the hardware components are built into the kernel while others reside as Loadable Kernel Module (LKM). LKMs extend base kernel when the corresponding functionality is required at runtime. Through the insertion and removal of those modules, efficient usage of memory is achieved. User Space hosts to all of the software that is necessary for better user experience. User Space programs interact with the kernel space when needed. The separation of Kernel Space and User Space provides the efficient and safe use of resources.

4.2

Realtime Linux Kernel

Standard Linux kernel is not suitable for real-time operation because it is designed to improve the common case performance. Realtime Linux kernel has a modified scheduler that supports Preemption. Existence of Big Kernel Lock (BKL) in Linux Kernel avoids Preemption of processes at the kernel space. In Realtime Linux Kernel, BKL is eliminated in all possible places. In addition, high-resolution timers are utilized in the Realtime Kernel to have system timer accuracy under 1µs. One of the biggest advantages of using Realtime Linux is, there is no need to use a specialized API for real-time processes. Realtime Linux is POSIX-compliant, therefore, operations on real-time processes is quite easy with this interface.

4.3

Configure and Build Realtime Linux Kernel

Realtime Linux kernel is handled by patching corresponding mainline kernel with the real-time patch. Realtime Kernels merge from some mainline Linux Kernels. The latest mainline kernel that real-time patches are being developed is 2.6.33.7, though currently 2.6.39.2 is available do use. The latest stable kernel and the RT-Preempt patches are available online [6],[7]. After downloading kernel and its real-time patch, extract and patch the mainline kernel with the following commands.
cd / u s r / s r c / k e r n e l s wget www. k e r n e l . o r g /pub/ l i n u x / k e r n e l / v2 . 6 / l i n u x − 2 . 6 . 3 3 . 7 . t a r . bz2 t a r − j x f l i n u x − 2 . 6 . 3 3 . 7 . t a r . bz2 mv l i n u x − 2 . 6 . 3 3 . 7 l i n u x − 2 . 6 . 3 3 . 7 . 2 − r t 3 0 cd l i n u x − 2 . 6 . 3 3 . 7 . 2 − r t 3 0 wget www. k e r n e l . o r g /pub/ l i n u x / k e r n e l / p r o j e c t s / r t / o l d e r / patch − 2 . 6 . 3 3 . 7 . 2 − r t 3 0 . bz2 b z i p 2 −d patch − 2 . 6 . 3 3 . 7 . 2 − r t 3 0 . bz2 patch −p1 <patch − 2 . 6 . 3 3 . 7 . 2 − r t 3 0

Before building real-time patched kernel, several changes should be made to the kernel configuration file. Open the configuration file with and make the following changes.
make me nuc onfi g

7

Enable HPET Timer Support and select Preemption Mode as Complete Preemption (Real-Time) shown in Figure 3. Disable tickless kernel and enable the High Resolution Timers as in Figure 4.

Figure 3: Configuration I

Figure 4: Configuration II

8

Compile, link and install the new kernel:
make make m o d u l e s i n s t a l l install

Then linux bootloader (GRUB) should be updated to recognize the new kernel while booting up.
update−grub

After booting with the Realtime Linux, one should be aware of capabilities of the real-time kernel. Cyclictest is a tool that can measure real-time performance. It tests wake up latencies of high priority real-time task with highresolution timer. While running cyclictest a proper stress should be application to measure the actual real-time performance. As the non-real time operating system performs quite well under idle conditions, tests will be meaningful with some load. Checkout and build the rt-tests utility to use the cyclictest as follows.
g i t c l o n e g i t : // g i t . k e r n e l . o r g / pub /scm/ l i n u x / k e r n e l / g i t / c l r k w l l m s / r t −t e s t s . g i t cd r t −t e s t s make a l l cp . / c y c l i c t e s t / u s r / b i n / c y c l i c t e s t −a −n −t −p99

This test will spawn one thread for each of your processor cores. Processes will have the highest possible priorities and test will continue to run until interrupted.

4.4

Programming with Realtime Linux

POSIX.1b includes real-time extensions that provides Priority scheduling, Realtime signals, Clocks and Timers, IPC and so on. In order to use these functionalities, programmers should link their projects with the real-time library using the option -lrt. There are two critical things to do while programming real-time processes with Realtime Linux. Firstly, paging should be eliminated with the command mlockall. MCL FUTURE option provides dynamic memory allocation at runtime will also reside on RAM and notifies if there is no space available. In addition to disabling paging, we should set priorities of the processes with sched setscheduler command. Lowest priority process has a priority of 1 and for the highest process it is 99.

9

i n t main ( i n t a r g c , char ∗∗ a r g v ) { m l o c k a l l (MCL CURRENT | MCL FUTURE) ; /∗ Lock a l l p r o c e s s memory p a g e s i n RAM( d i s a b l e p a g i n g ) ∗/ struct sched param s c h e d u l i n g p a r a m e t e r s ; scheduling parameters . sched priority = sched get priority max ( SCHED FIFO) ; s c h e d s e t s c h e d u l e r ( 0 , SCHED FIFO , &s c h e d u l i n g p a r a m e t e r s ) ; // u s e r code g o e s h e r e . . . m u n l o c k a l l ( ) ; /∗ u n l o c k p r o c e s s memory p a g e s i n RAM∗/ }

10

References
[1] Shen, Wu, Li, Zhang, Research of The Real-time Performance of Operating System. 2009. [2] Barr, Michael, Choosing an RTOS, Embedded Systems Programming. January 2003. [3] http://www.osadl.org [4] http://www.gnu.org/licenses/gpl.html [5] Elsir, Sebastian, Voon A RTOS for Educational Purposes [6] www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.33.7.tar.bz2 [7] www.kernel.org/pub/linux/kernel/projects/rt/older/patch-2.6.33.7.2rt30.bz2

11

Sign up to vote on this title
UsefulNot useful