Comparison of Real-Time Scheduling in VxWorks and RTLinux

Transcription

1 Comparison of Real-Time Scheduling in VxWorks and RTLinux TDDB72: Concurrent Programming, Operating Systems, and Real-Time Operating Systems Jacob Siverskog Marcus Stavström November 19, 2006

2 Contents 1 Abstract 2 2 Introduction 3 3 VxWorks States Scheduling Preemptive Priority Scheduling Round-Robin Scheduling No Scheduling RTLinux RTLinuxPro A Dual-Kernel Approach Linux Kernel Performance Enhancements Real-Time Scheduling Algorithms SCHED FIFO: First In-First Out Scheduling SCHED RR: Round-Robin Scheduling Comparison of scheduling in RTLinux and VxWorks 8 6 Conclusion 9 7 References 10

3 1 Abstract This document describes and compares the CPU scheduler and task management of the realtime operating systems VxWorks and RTLinux. In chapter three and four VxWorks and RTLinux will be described briefly, and in chapter five they will be compared and the differences will be examined.

4 2 Introduction In this report some specific real-time issues in the real-time operating systems VxWorks and RTLinux will be compared. There are some events from different applications that need direct assistance by a system that can perform the appropriate type of action. Often it is not necessary to know exactly what the maximum time for a system response is. However, some of these events can have disastrous consequences if the proper action cannot be performed within a certain time. Therefore, systems that are reliable and predictable regarding system response time are necessary. Operating systems with these properties are called real-time operating systems. Real-time operating systems is something most people use daily, many of the electronic devices used contains one or more microprocessors which often runs real-time software. Examples of such applications are mobile phones, network controllers and cars. It is often necessary to organise a set of jobs which the operating system is supposed to accomplish. However, the CPU can only execute one program at a time. The CPU scheduler is a technique used to make these jobs appear like they are running concurrently. It switches between the jobs according to a scheduling policy, which is an algorithm that chooses when and how often a specific job should be run. The scheduler is an essential part of the operating system, in particular in real-time operating systems. In this report, the schedulers of two commonly used real-time operating systems (VxWorks and RTLinux) will be examined and compared. There are two types of real-time systems; hard real-time systems and soft-real time systems. The former describes a system which must response to a command within a specific time interval. The system must meet these deadlines, failure of meeting these deadlines can for some applications have catastrophic consequences. A soft real-time system is also a time critical system, but there is no catastrophe if a deadline is missed. Not meeting deadlines are therefore accepted but nothing to strive for.

5 3 VxWorks (The only reference used in this chapter is the VxWorks Programmer s Guide) VxWorks is one of the most common real-time operating systems in the embedded industry. Examples of products using VxWorks are NASA s Mars exploration rovers (Spirit and Opportunity), Boeing s 787 airliner and ABB s industrial robots. It is an operating system that supports multitasking. In this chapter, the task management in the VxWorks operating system will be covered briefly, including the scheduling of tasks in the operating system and some properties of these scheduled tasks. The operating system is designed with the property of smart and fast context switches. There is no particular loss of CPU time of switching between two jobs, which is a great advantage in real-time operating systems. In VxWorks, a resource valuable for the real-time operating system is not a part of a task context memory. All tasks executes in a single address space. If all tasks were given their own address spaces, the operating system would have to perform a virtual-physical memory mapping. This kind of memory management is optional and can be performed if the component VxVMI is installed. VxWorks is a commercial hard real-time operating system, which means that the operating system guarantees that the deadlines always are met. 3.1 States In VxWorks there are four major states which a task can be in; suspended, ready, pended and delay state. States are used to identify the condition of a process, which is necessary for a scheduler. When a task is created, it enters its suspended state. Entering the ready state from the suspended state requires an initialisation of the task, these initialisations are very fast. This is an excellent advantage of the VxWorks operating system, because tasks can create new tasks within a small amount of time. When the task has entered the ready state, it will be able to execute. A task can be pended, which means that the task is requesting some resource that is busy, for example an I/O operation. There is also a delay state for the tasks. Typical applications for this state are when the task is waiting for something, for example while writing data to a hard drive. A task can exist in two or more states at the same time, but this feature will not be covered in this report. 3.2 Scheduling VxWorks uses two types of CPU schedulers; the Wind scheduler and the POSIX scheduler. These are interfaces used to increase portability. The Wind scheduler is especially designed for the VxWorks kernel, while the POSIX scheduler is a set of standard routines for real-time operating systems. There are some differences between these schedulers. Wind scheduling is based on tasks, while the POSIX scheduler is based on processes. The Wind scheduler splits its programs into smaller tasks, and therefore the scheduling becomes more flexible. While the POSIX scheduler uses first in-first out scheduling as standard, the Wind scheduler uses preemptive priority scheduling.

6 There are some differences between a task and a process. Tasks can access the main memory directly, while processes cannot. Another difference is the how the context is handled. Processes operate in its own context, and inherit only small attributes from its parent. A task operates in the same context as its parent. The POSIX scheduler is not considered any further in this section of the report; hence, a more thorough analysis of the Wind scheduler will be made. The Wind task scheduler in VxWorks is quite simple. There are two types of scheduling methods; preemptive priority scheduling and round-robin scheduling. A programmer has the opportunity of choosing scheduler depending on the actual application. 3.3 Preemptive Priority Scheduling With a preemptive priority scheduler, the operating system guarantees that the task with highest priority is executed first. For example, if a task with a certain priority is running, and another task with a higher priority requests to execute, then the currently running task will immediately be preempted and the task with the higher priority will be executed. When the task with the higher priority has finished, the next highest priority task is executed by the operating system. In the VxWorks Wind scheduler there are 256 priority levels to choose among, ranging from 0 (highest priority) to 255 (lowest priority). 3.4 Round-Robin Scheduling The round-robin scheduling algorithm is a more fair scheduling algorithm than the preemptive scheduling algorithm. This algorithm attempts to share the CPU among tasks with the same priority, which was not the case with the preemptive priority scheduler. Tasks with the same priority will get the same amount of CPU time from the scheduler. When the processor has executed a task for a specific time, the scheduler switches to another task with the same priority and run this task for the same specific time. Context switches takes time, and it may seem unnecessary to switch between tasks like this. However, the main priority when designing the VxWorks was fast and smart context switches, these context switches are quick and the loss of CPU time is somewhat insignificant. If a task with a higher priority requests to run, the operating system will run that task immediately and it will run until it finishes. When the higher priority task finishes, the operating system switches back to the lower priority task, assumed there is no other higher priority task pending. 3.5 No Scheduling When executing a task, there is an opportunity of disabling the scheduler. When the scheduler is disabled, no priority-based preemption can take place when that task is running.

7 4 RTLinux There are two different techniques to get real-time capabilities into the Linux kernel. One method is to implement an abstraction layer beneath the mainline Linux kernel, and the other one is to enhance the real-time features of the kernel by improving its performance in various ways. The former is a hard real-time solution while the latter only provides soft real-time. This report will be focused on two of the most active approaches to a real-time Linux kernel. One project is RTLinuxPro, which is a dual-kernel implementation developed by FSMLabs. Another project currently under heavy development is the modifications made to the standard kernel developed mainly by embedded Linux vendors TimeSys and MontaVista and Linux kernel developer Ingo Molnar (employed by Linux distributor Red Hat). In fact, RTLinuxPro benefits from the other project s work because it takes advantage of their kernel which provides soft real-time support. (Real-time Linux Software Quick Reference Guide; Dankwardt, 2000) 4.1 RTLinuxPro A Dual-Kernel Approach In this approach, the Linux kernel is executed on top of a small real-time kernel (RTCore). RTCore runs the Linux kernel as an idle thread at lowest priority. This approach is called RTLinuxPro by its vendor FSMLabs. It is a commercial project supported by FSMLabs, which also provides a functionally limited version called RTLinuxFree at no cost for free-software development. Real-time applications written for the RTCore kernel are executed at a higher priority than the Linux kernel, and have a variety of communication methods for accessing applications running on top of the Linux kernel. The RTCore provides a standard POSIX threads API for programming real-time applications and follows the POSIX PSE51 (minimal realtime system profile) specification. By abstracting the soft real-time kernel from the hardware, FSMLabs manage to achieve hard real-time. (Dankwardt, 2000) 4.2 Linux Kernel Performance Enhancements Beginning in version 2.6, both preemptive capabilities and O(1) (constant time) scheduling have been implemented into the mainline Linux kernel. These improvements brings greater performance and better event response time prediction, which are important issues for real-time operating systems. Much work is currently being done to get additional real-time technology into the mainline kernel. Before, these improvements have only been available as kernel patches and in forked patched kernel trees maintained by the developers. Beginning with Linux kernel , some of these patches are included in the standard kernel. Over the next few years, most of the work done is expected to be merged into the mainline kernel. One of the efforts being made is an attempt to minimise the amount and length of critical code sections. These blocks of code are not preemptable, which makes it more difficult to predict response times. The interrupt threads approach is another attempt to deal with this problem; they make it possible for interrupt service routines (ISR) to be executed within a kernel thread context. Normally, ISR:s are executed at a higher priority than system tasks, which makes the original implementation unsuitable for real-time systems. Another change is the high resolution timers framework (hrtimers) which will increase the prediction ability even further. The modifications are released to the public under a free software licence. (Cesati and Povet, 2005; Gleixner, 2005; Kerner, 2006; von Hagen, 2005)

8 4.3 Real-Time Scheduling Algorithms In version 2.6 of the Linux kernel, every process is scheduled according to one of the following three scheduling policies: SCHED FIFO, SCHED RR and SCHED NORMAL (sometimes denoted SCHED OTHER). The first two applies to real-time processes while the latter is for normal timesharing processes. Since the focus in this report will be kept on real-time computing, only SCHED FIFO and SCHED RR will be taken into consideration. Every process is assigned a static priority value (often called niceness ), this value is used by the scheduling algorithm when choosing when and how often it will run the process. The static priority value is always inherited from the process parent, however, it is possible to change the static priority of the process by the nice(), sched setparam() and setpriority() system calls. The static priority values are seen from normal non real-time user programs as a number ranging from -20 (highest priority) to 19 (lowest priority). By default, the Linux kernel has 140 priority levels internally, where values 1-99 are used for real-time tasks and are used for normal tasks. Since the real-time tasks always have a lower static priority value than the normal tasks, they are guaranteed to be chosen first by the scheduler. (Cesati and Povet, 2005; Linux Programmer s Manual, 2006) SCHED FIFO: First In-First Out Scheduling SCHED FIFO implements a simple first in-first out algorithm for scheduling, with no timeslices. The task will run until it either blocks a resource or yields the processor, even if there are another runnable real-time process with the same priority. If a process with higher priority preempts the currently running process, the scheduler will put the current process at the beginning of the list for its priority. When all processes of higher priority are blocked or finished, it will resume execution of the preempted process. (Cesati and Povet, 2005; Linux Programmer s Manual, 2006) SCHED RR: Round-Robin Scheduling SCHED RR is basically SCHED FIFO with added time slicing; if a SCHED RR process has reached the specified time quantum, it will be put on the end of the list for its priority. This policy ensures fair assignment of resources to processes with the same priority. (Cesati and Povet, 2005; Linux Programmer s Manual, 2006)

9 5 Comparison of scheduling in RTLinux and VxWorks Both VxWorks and RTLinuxPro are true hard real-time systems, while the Linux real-time extension approach are only soft real-time. This aspect is very important for many industrial time critical applications where deadlines must be guaranteed to be met. Since the requirements of hard and soft real-time systems differ a lot, we mainly compared RTLinuxPro and VxWorks. The hard real-time systems are both commercial, while the standard Linux kernel enhancements are released under a free licence. However, there are several real-time Linux vendors which offer commercial support for these modifications. Both the VxWorks and RTLinuxPro operating systems use the same policies of real-time scheduling; preemptive first-in first-out scheduling and round-robin scheduling. What differ more are the underlying implementations and other design choices. Some examples where the systems differs significantly: Priority levels; RTLinux distinguishes between real-time and non real-time processes while VxWorks handles all applications using real-time policies. RTLinuxPro uses two kernels to obtain hard real-time property, while VxWorks only uses a single kernel.

10 6 Conclusion When choosing these operating systems, we were expecting that the real-time schedulers of them would differ more. After investigating the real-time schedulers of VxWorks and RTLinux, we concluded that finding significant differences between them was difficult because they are so similar. What differed more was the rest of the systems, which had less in common. Finding trustworthy sources of information for VxWorks were quite easy, with a good programmer s guide available. With the non-commercial Linux kernel extensions, however, the situation was not the same. Since there are not really a vendor in the same sense available to turn to, we had to find others sources of information.

11 7 References Cesati, Marco & Povet, Daniel P (2005). Understanding the Linux Kernel. O Reilly Media, 3rd edition. Dankwardt, Kevin (2000). Comparing real-time Linux alternatives [www] < Gleixner, Thomas (2005). Patch: ktimers subsystem [ ] <tglx@linutronix.de. to the Linux Kernel Mailing List, 19 sep 2005.> Kerner, Sean Michael (2006). Real Time Coming to Linux Real Soon [www] < von Hagen, William (2005). Real-Time and Performance Improvements in the 2.6 Linux Kernel [www] < Real-time Linux Software Quick Reference Guide [www] < Linux Programmer s Manual sched setscheduler() Linux Kernel manual page (2006) VxWorks Programmer s Guide 5.5 [www] <