Two Real-Time Operating Systems and Their Scheduling Algorithms: QNX vs. RTLinux

Transcription

1 Two Real-Time Operating Systems and Their Scheduling Algorithms: QNX vs. RTLinux Daniel Svärd Freddie Åström November 19, 2006 Abstract This report tries to give an overview of the different scheduling algorithms that are used in RTLinux and QNX Neutrino. Both systems are hard realtime operating systems widely used in industrial applications. Algorithms are described, evaluated and then compared between the different systems. Information contained in this document can be considered as a basis for further investigation and development of scheduling algorithms based on these systems. QNX has more default choises for scheduling than RTLinux has. Its sporadic scheduling algorithm is very effective in systems with mixed periodic and aperiodic tasks. RTLinux on the other hand has access to more options with its modular organization. 1 Introduction The two real-time operating systems QNX and RTLinux are common operating systems used in industrial applications where hard deadlines are required. Meeting hard deadlines requires effective systems where scheduling is a crucial part. In this report we will investigate how these two operating systems have solved this problem and how they differ. The first part of the document identifies the problems of scheduling real-time tasks in an operating system; the second part describes how these problems are solved in QNX and RTLinux respectively; and the third part of the document discusses the differences between the two systems. 1

2 2 Scheduling Real-time operating systems differ very much from general purpose operating systems in terms of scheduling. Realtime operating systems run tasks that have fixed deadlines. These deadlines are important to be held - especially in hard real-time systems - since failing to do so might have catastrophic consequences. To guarantee that a task is run before its deadline, the system needs to service a task as soon as it requests the CPU. To accomplish this, the real-time system needs to have a priority-based scheduler. This means that all tasks are given priorities and based on those, the scheduler decides which task to run next. The scheduler also needs to be preemptive, meaning that it should be able to stop a task from running before it is finished and switch to another task. This strategy is used when a task with higher priority than the currently running task becomes availible to run. Since it has a higher priority it needs to be given the CPU, regardless of whether the current task is finished or not [1]. The preemptive strategy creates some problems with synchronization when shared resources are used. Consider three tasks with low, medium and high priorities respectively. The low task locks on a mutex for a shared resource. The high task then blocks on the mutex. The medium task will now preempt the low task preventing it from making progress and releasing the mutex. This will prevent the high task from running and it will probably miss its deadline. Methods for solving this problem is, however, out of the scope of this report, and will not be discussed further. Priority-based preemptive scheduling algorithms only ensures soft real-time functionality. To provide hard real-time functionality, the system must also guarantee that deadlines are met [1]. 3 QNX QNX Neutrino is designed to be a hard real-time operating system. An efficient task-management system is based on the idea that every part of the microkernel should be divided into small servers that can be controlled separately by a system operator. Different hard-real time systems have different models for structuring the kernel. QNX is mainly used in industrial applications such as telecommunications and medical instruments that need high reliability [2]. A convention for QNX is that a process can hold one or several tasks. Consider it as a shopping-bag: the bag (process) contains the groceries (threads or tasks). 3.1 The Microkernel In QNX Neutrino s case effort has mainly been focused on keeping the kernel structure as small as possible, non-critical system modules should be easy to replace. 7 The microkernel only includes CPU scheduling, interprocess communication, interrupt redirection and timers. Other crucial parts of the system management such as memory management and filesys- 2

3 tems are run as user processes in separate modules [3]. 3.2 Global Task Priority When the state of execution of a thread change, it is possible for the scheduler to make scheduling decisions. Context switch will occur when the current executing process is either blocked, yielded or pre-empted [1]. All threads use one of 64 priority levels where 63 is the highest and 0 is idle. For every level of priority there can be multiple threads waiting to be executed, note that it is only the first thread in the highest priority level that can be set to the Run state. After this thread has finished its execution or is pre-empted by the scheduler it is possible for other threads to receive execution time. Priority level can be decreased or increased by the scheduler to ensure that a thread never will starve. In this process the thread that just had its priority modified will be appended to the end of the new priority level queue [3]. It is only the kernel that can decide which priority level a thread should be given. This can happen in two ways. Either the kernel itself decides which priority a given thread should be given or a thread with higher priority level can request the kernel to give another priority level to a specific thread [3]. 3.3 Scheduling Algorithms There are mainly three different scheduling algorithms in QNX Neutrino, these are FIFO (First In First Out), RR (Round Robin) and Sporadic scheduling which are POSIX scheduling policies [4]. The first two algorithms are well known and will only be considered briefly. However the Sporadic scheduling algorithm will be further investigated FIFO and RR First-In First-Out also known as FCFS (First-Come First-Serverd) is an ordinary linear queue which will schedule the first task to enter the queue as readyto-run. Computation of a new task will start when the currently running task is either pre-empted by a task with higher priority or if it relinquish the cpu. Round Robin or RR is a FIFO with a few additional conditions. In QNX Neutrino s implementation the algorithm will schedule a new thread as ready-to-run when the current running thread either have finished its computations, is preempted or has consumed its time slice. Here a time slice has a length of 4 times the clock period Sporadic Scheduling This algorithm is mainly used when the system is known to have stochastic computation tasks or if it is suggested that the system will be affected by hardware issues causing irregular computation times for the same task [4]. The Sporadic scheduling algorithm gives the system the ability to handle aperiodic tasks [4]. The sporadic scheduler is a scheduler that uses predefined parameters for execution period, replenishment time, initial 3

4 time budget for a thread and priority for thread execution order. There is also a maximum amount of replenishments [3]. Execution time - Time that the thread has been holding the CPU. Replenishment period (T) - Time left for another thread to hold the CPU after the current thread is finished execution within the time budget (time period) that was given to the thread. Time budget (C) - Time given to a thread for execution. If thread is not finished within this period of time it is pre-empted, providing that there is another thread waiting to be run. Priority - Each thread is given a priority in the foreground, normal priority, and in the background the thread can be given low priority. Note that the priority of a given thread can oscillate between these different levels of priority. Time of replenishments - A result of many replenishments is that many context switches will occur which is time consuming. Therfore, the number of times a thread is replenished should be kept at a minimum. The times of replenishments is bounded by the system [3]. Figure 1. Example of sporadic scheduling with period T = 40 ms [3]. When a thread or task is given CPU-time its priority-level drops to lowpriority in the foreground. This ensures that if there is another thread with higher priority than the current one being executed it can pre-empt the current one and take hold of the CPU. The current thread can also be blocked. If this is the case then the thread that was pre-empted or blocked will have its previous priority reinstated. At the end of the replenishment period the thread will be given a new chance to take hold of the CPU. 3.4 Comparison of Scheduling Algorithms FIFO has the obvious disadvantage that if a task with a large computation time is scheduled to run it will probably hold the CPU to long. If this happens it will most likely cause other tasks behind it waiting to be run to not be able to meet their deadline. On the other hand FIFO is a sufficient algorithm for just a few tasks. Round Robin on the other hand is an extension of FIFO with a few conditions. If the time slice in RR is large enough or if the number of threads that is served is small enough RR will behave as the FIFO algorithm. Assume 4

5 we set the time slice for replenishment small enough it can cause the algorithm to make too many context switches causing the CPU to only be busy moving data around which is not desirable. Therefore the replenishment time must be set to adopt to the current applications running on the system. There is also a possibility for threads with higher priorities to preempt the currently running thread, which is not possible in FIFO. Sporadic Scheduling is similar to RR in many aspects but two of the major differences are the priority hierarchy and the way it deals with a large number of replenishments. It is not hard too realise that RR can cause a large number of replenishments causing a large system overhead, the Sporadic scheduling algorithm has an built in mechanism that ensures that the number of replenishment don t exceed a bounded system constant. As the number of replenishments is growing the algorithm automatically gives a larger time budget to the thread giving is a chance to finish its computation. The Sporadic algorithm is preferably used when the number of tasks that are processed is large. 3.5 Latency Latency time is very difficult to determine since it is strongly dependent on which architecture the system is run on. 4 RTLinux RTLinux is a soloution for running realtime tasks together with Linux. It is maintained by Victor Yodaiken at Finite State Machine Labs. It is not a try to implement real-time capabilities to the general purpose operating system Linux; since this would be very difficult considering that real-time system requirements often contradict requirements for general purpose systems [5]. Instead, RTLinux has its own core that is decoupled from the Linux kernel. The RTLinux core has the control over the hardware interrupts and provides an interrupt emulation layer for Linux. When Linux tries to disable the interrupts, RTLinux records it and returns to Linux, thus ensuring that Linux cannot actually disable interrupts. The Linux kernel is run as the idle task of the system, i.e., it runs when there is no other task that needs to use the CPU. This means that Linux cannot add latency to the system and enables the system to service real-time tasks, while also providing the system with all the general purpose operating system capabilities of Linux [6]. RTLinux follows the POSIX standard. This standard is not as comprehensive as the original POSIX standard, that contains many operations that would be impossible to implement in a system in need of a small footprint. The real-time tasks in RTLinux are therefore implemented as POSIX threads [7]. 4.1 Scheduling Algorithms RTLinux is a modular system, allowing components of it to be replaced by others. For example, the scheduler that is distributed with the system is a module. 5

6 If it does not suit the requirements for an application, there are other scheduling modules that might. RTLinux comes with a static priority scheduling module, that always runs the thread with the highest priority. There are also other contributed modules that support different scheduling algorithms, such as the earliest deadline first [6]. Although the earliest deadline first algorithm is not an official part of the system, it deserves to be mentioned here Priority Scheduling The default scheduler for RTLinux is a static priority scheduler. It ensures that the thread with the highest priority is run at all times. If a higher priority thread becomes runnable, the scheduler will preempt the currently running thread in favor for the higher priority one. This is known in the POSIX standard as FIFO scheduling. If two threads share the same priority 1, it is undefined which of them will take preference [9]. The scheduler contains a list of all the runnable threads in the system. Each time a new thread is about to be scheduled, the scheduler runs through the list and compares the threads priority values. The one with the highest priority in the list is then switched to [10]. The priority of a thread is set during its initialization through the thread s scheduling parameters structure. It is also possible to change the priority during the lifetime of the thread. This is useful for various synchronization protocols that work with priority inversion [9]. A drawback of this policy is that the timer clock needs to be reprogrammed at every timer interrupt. Depending on the underlaying architecture, this can be relatively time-consuming. Therefore, the scheduler also provides the possibility to make a thread periodic, in which case a thread will be scheduled to run at set intervals [6]. A periodic thread has to have its priority set in the same way as a nonperiodic thread. To set its period, it also has to call a function with arguments indicating the period as well as the first time it is to be executed [9] Earliest Deadline First The earliest deadline first module is not a complete replacement of the static priority module that comes with RTLinux. Instead it is an expansion of that module to support both the standard static priority algorithm and the dynamic priority earliest deadline first algorithm. Using the earliest deadline first algorithm, the scheduler will first go through the list of runnable threads searching for the thread with the highest priority level. If two threads share the same priority level, the thread with the closest deadline will be scheduled [11]. The only thing that the module changes in the scheduler code from the default module, is the comparison of only the priorites to the comparison of both priorities and deadlines. This is just a few lines of code, and the overhead is minimal. 1 As of RTLinux Version 3.1 there are one million priority levels availible [8]. 6

7 In addition, it adds a couple of functions for setting and getting deadlines to the scheduling API. These functions are used during the initialization of the thread at the same time as the priority is set. They can also be used later in the thread execution to change the deadline of the thread. There is nothing that says that the deadline of a thread has to be fixed. Because the earliest deadline first is a dynamic priority algorithm, the normal shared resource access protocol used by RTLinux cannot be used. The module thereby also includes another protocol called the Stack Resource Policy [11]. The description of that synchronization protocol is, however, out of the scope of this document. 4.2 Latency It is difficult to say much about task latency for a scheduler since it is very dependent on the underlaying architecture. For example, according to the RTLinuxPro Performance Datasheet [12] the worst case latency can differ from 13 to 104 microseconds on the x86 architecture, depending on the processor, motherboard and if the system uses Symmetrical Multi Processing (SMP) or not. 5 Discussion Developers from both RTLinux and QNX has given a great deal of thought to how to structure the kernel. Both systems have very small and lightwight kernels, only the most basic functions are implemented such as IPC and scheduling. RTlinux has one main scheduling algorithm implemented, FIFO, by default. Compare this to QX which has three by default. This is not necessarly a good thing, it makes the kernel larger, but on the other hand, QNX has a larger number of options for scheduling. Another big difference between the systems is that RTLinux treat all small separate modules for computation as different tasks which gives a very large number of priority levels. QNX has a different view of priority handling for scheduling. Their soloution means that there are processes and then tasks within each process. In other words the QNX developers has implemeded something similar to multilevel-queueing where each global priority has a sub-level containing a list of tasks with the same priority, which thereafter are scheduled accordingly. The obvious, and most interesting, is that RTLinux and QNX both have the FIFO scheduler implemented but using the algorithm very differently. RTLinux use it to schedlue tasks for the whole system while QNX only use it for a small number of tasks within each priority level at a global perspective. Remeber that both systems are under development and ecpecially RTLinux is very young considering that the global queue with priorities have about one million levels and for each time the system will find the task with the highest priority RTLinux will have to search throu the whole list and make one comparison between the current task with highest priority with the next in the list. This method of search 7

8 algorithm holds the CPU, in the worst case, for O(n) long time. As for dynamic priority algorithms, RTLinux provides the Earliest Deadline First (EDF) algorithm and QNX the Sporadic Scheduling algorithm. These two are very different in the way they work, but they both are used in situations when task run times are not fixed. The sporadic scheduling ensures that hard deadlines of periodic tasks are not missed because of aperiodic tasks. The sporadic scheduler makes this feature possible beacause of the replenishment method that EDF lacks. Consider a system with a missconfigured number of replinshement times and the consequences of it. If the amount of replenishments are too low it will cause the system to give low-priority threads with long execution times hold of the CPU too fast and too long time, causing threads with higher priority to not be able to be executed within their deadline, this is one example of a missconfigured system. An important advantage of the EDF is that it is theoretically optimal. That means that it is able to schedule its tasks to meet their deadlines while keeping the CPU utilization at 100%. The RTLinux implementation of the EDF algorithm is not entirely dynamic. It does not actually change the priorities of the tasks with regards to their deadline requirements. Instead, it only uses the deadline as a priority factor when two or more processes share the same priority level. However, if the system designer keeps all the tasks at the same priority level, the desired effect is attainable. Note that real-time operating systems very much depend on the configuration of the system conserning the environment it is supposed to operate within. A direct cause of the environment one must consider is the number of applications running concurrently and the amount of computations needed for every task. References [1] A. Silberschatz, G. Gagne, and P. B. Galvin, Operating System Concepts. John Wiley & Sons, Inc., seventh ed., [2] C. L. Wang, B. Yao, Y. Yang, and Z. Zhu, A Survey of Embedded Operating System. [3] QNX, Development Documentation. QNX Software Systems, docs/momentics621 docs/neutrino/ sys arch/kernel.html, [4] QNX, Maximizing Performance with SMP: Design Application to Run on Multiple, Tightly Coupled Processors. QNX Software Systems, [5] FSMLabs, Real-Time Programming in RTCore. Finite State Machine Labs Inc., August [6] V. Yodaiken, The RTLinux Manifesto. New Mexico Institute of Technology, November [7] V. Yodaiken, FSMLabs Lean POSIX for RTLinux. Finite State Machine Labs Inc.,

9 [8] M. Barbanov and V. Yodaiken, rtl sched.h line: 194, in RTLinux Version 3.1 Source Code. Finite State Machine Labs Inc., [9] M. Barbanov, Getting Started with RTLinux. Finite State Machine Labs Inc., [10] M. Barbanov and V. Yodaiken, rtl sched.c line: , in RTLinux Version 3.1 Source Code. Finite State Machine Labs Inc., [11] P. Balbastre and I. Ripoll, Integrated Dynamic Priority Scheduler for RTLinux. Universidad Politécnica de Valencia, [12] FSMLabs, RTLinuxPro Performance Datasheet. Finite State Machine Labs Inc.,