Comparison of scheduling in RTLinux and RT-Mach Fredrik Löfgren frelo305 Dan Persson danpe454

Transcription

1 Comparison of scheduling in RTLinux and RT-Mach Fredrik Löfgren frelo305 Dan Persson danpe454

2 Abstract Real-time systems are getting more common the world these days. They are used in many embedded systems which most people are using daily without noticing. However we grow more and more dependent on them and their reliability. That is why real-time systems are used in many embedded systems. The most important issue of a hard real time system is to be able to keep a set deadline. Not being able to do so may cause serious negative effects. To be able to keep the deadline, the system needs good tools and algorithms for scheduling. This report will look deeper into two real-time systems, RT-Mach and RTLinux, and their ways to handle scheduling. Are there any differences? The two systems are both different and alike. When it comes to scheduling they both have shared algorithms and though RT-Mach has some more to choose from there is no reason to choose one over the other because of scheduling. 1

3 Index 1 INTRODUCTION REAL-TIME LINUX PURPOSE OF RTLINUX PRINCIPLES OF RTLINUX SCHEDULING IN RTLINUX REAL-TIME MACH BACKGROUND THE MACH KERNEL SCHEDULER AND RT-MACH NR ALGORITHMS EARLIEST DEADLINE FIRST FIXED PRIORITY SCHEDULING RATE MONOTONIC ALGORITHM FIRST IN FIRST OUT MINIMUM SLACKTIME FIRST SHORTEST PROCESSING TIME FIRST ROUND ROBIN TIME SHARING DISCUSSION ALGORITHMS PRIORITY INVERSION HANDLING CONCLUSION REFERENCES

4 1 Introduction This report will give a very brief description of the systems in general and go a bit deeper into their scheduling mechanism. We start out by describing each system separately and then following up with a deeper description of the algorithms they use. After that we have a discussion of their way of scheduling. At the end we try to make a conclusion on which system to choose from a scheduling perspective. 3

5 2 Real-Time Linux 2.1 Purpose of RTLinux There are two versions of RTLinux available, RTLinuxFree and RTLinuxPro. RTLinuxFree is a free version with open source, making it possible to modify the kernel as you wish. RTLinuxPro is distributed by FSMLabs 1 and is not free, but this version support a lot of more platforms than RTLinuxFree, such as PowerPC, ARM9, SMP VME etc. You also get some services and support from FSMLabs when buying their version. RTLinux was created with one goal in mind; an operating system that provides hard real-time features and fulfils the requirements for a hard real-time system, but still have the functionality of a GPOS. Prior attempts of making Linux a hard real-time system includes the idea of extending the Linux API, POSIX, with hard real-time system functionality. But simple tests showed that if the Linux-system was heavily loaded by ordinary non-real-time tasks, the real-time tasks were considerably delayed and this affected the worst-case delay time. In a hard real-time system, it doesn t matter how good the average delay time is, since a missed deadline is as bad as a miscalculation. So a good average delay time can t make up for a bad worst-case delay time. [1] 2.2 Principles of RTLinux Instead of change/extend an existing OS and add real-time functionality, the developers of RTLinux took another approach. They have kept the ordinary Linux-core, but they have also made a new, small real-time core (called RTCore). This new RTCore treats the ordinary Linux-core as its idle-thread, which means that as soon the RTCore is out of work, it runs the ordinary Linux-core. RTCore works as a virtual machine for the ordinary Linux-core, limited to the interrupt-handling. When an interrupt is pending, it is first checked if the RTCore contains any driver/routine to handle the interrupt. If there is one, the routine will be marked as ready-to-run and the RTCore will take the appropriate action, depending on which scheduling algorithm is used. If there is no routine for the interrupt in the RTCore, the interrupt will be sent to the ordinary Linux-kernel. [1] RTtask 1 RTtask 2 User process 1 scheduler User process 2 Linux kernel I/O drivers Interrupts I/O RT-scheduler RT-Linux kernel (RTCore) Interrupts Figure 1 Principles of RTLinux [6] Hardware 1 4

6 2.3 Scheduling in RTLinux As seen in picture 1, there are two different schedulers in RTLinux, one in the RTCore and one in the ordinary Linux-kernel. This makes it possible to use different scheduling algorithms in RTCore and the ordinary Linux-kernel. Since RTCore, just like ordinary Linux, consists of modules, it is easy to compile the RTCore using another scheduler-module, which in practice means you can use what ever scheduling algorithm you want. But as standard there are two different simple scheduling algorithms to choose between, rate monotonic scheduling and earliest deadline first. There are also other features in RTLinux concerning the scheduler. There is a feature called Frame Scheduler. This technique can be used by developers when the real-time application doesn t require an advanced scheduling algorithm. The frame-scheduler allows the developer to test different scheduling-properties, such as period time, without recompiling the program after each change. Instead the developer sets the period time via a command interface. Another feature in RTLinux is the advance timer. This timer can be used to reduce the jitter (the time between when the task is supposed to run and the time the task really starts running). Say for example you have a task that can tolerate a worst case jitter of 5 us, and the delay in running the scheduler and making the context switch in worst case is 20 us. As you can see, the tasks jitter-demand isn t fulfilled. But if you set this advance timer to 20 us, the scheduler will schedule this task 20 us before the task has asked to run. When the context switch is done, the CPU is set to waiting-stage, until the start signal arrives. When the starting signal arrives, the CPU starts running the thread, and the threads starting time has deviated only a few microseconds from when it was supposed to start. Note that the CPU may be in waitingmode a few microseconds using this technique, so one may say you have traded computation time against smaller scheduling jitter. Also note that you must know when the task is supposed to run to be able to schedule it in advance. [2] 5

7 3 Real-Time Mach 3.1 Background In 1985 a group from the School of Computer Science, Carnegie Mellon University (CMU), Pittsburgh, Pennsylvania, started The Project Mach. The project was active until [3] That work was the base of RT-Mach. Work on RT-Mach had started before The Project Mach was finished and was also continued by another group from the same university. Until the latest version of RT-Mach, RT-Mach NR2.0, released in 1999 by the NTT laboratory group, RT-Mach the development was done by many independent groups. That release was based upon some previous versions of RT-Mach. [4] The objective of RT-Mach was to develop a predictable and reliable real-time version of Mach. 3.2 The Mach Kernel As mentioned above RT-Mach has been developed since the years when the project started until the latest version in The base of the RT-Mach was the Mach kernel. The RT-Mach kernel and particularly the scheduling are enhanced so it can work in real-time. The Mach kernel supports multiprocessors. It is built around two objects, a processor and a set of processors simply called processor set. Each processor set contains one or more processors and each set has its own scheduling queue and scheduler. This will make it ably to run different scheduling algorithms at the same time. A processor is in the same processor set at all time so when a thread leaves the processor it returns to the scheduler it came from before entering the process. [5] In the early versions there were only two algorithms for scheduling, Fixed Priority (FP) and Round Robin (RR). Later others have been implemented and in the middle of the 90s it contained the algorithms Earliest Deadline First (EDF), Rate Monotonic (RM), Fixed Priority (FP) and Time Sharing (TS). There was also a possibility of letting a thread be in the background and only run if no other thread needed the processor. [6] 3.3 Scheduler and RT-Mach NR2.0 With the latest version of RT-Mach, RT-Mach NR2.0 two tools, Scheduler and Advanced Real-time Monitor (ARM), is included to make it easier for the programmer,. Scheduler was developed simultaneously as the ARTS-project at CMU. [7] Scheduler is using the X window system, X11, and it can be used for analysing how the program is run by any of the pre-programmed algorithms. There is no source whether these are the algorithms which are used in RT-Mach NR2.0 but it can be seen as likely. The preprogrammed algorithms are Earliest Deadline First, Rate Monotonic, Round Robin, Fixed Priority, First In First Out, Minimum Slack Time First and Shortest Processing Time First. [8] 6

8 4 Algorithms 4.1 Earliest Deadline First Earliest Deadline First (EDF) is a dynamic scheduling algorithm using priority queues. When the scheduler runs, it searches for the task with earliest deadline and give this task highest priority, and this will be the one to run. If a real-time task already is running, but a new realtime task is released and has an earlier deadline, the first task will be pre-empted and the recently released task will be run since it has earlier deadline (and thereby higher priority). If the recently released task has later deadline, it will be put in the ready-queue. [9] Consider an example with three processes P1, P2 and P3 with the following properties: Table 1 Process CPU-time Release-time Deadline P P P P3 P2 P2 cont. 0 P t Deadline P1 Deadline P3 Deadline P2 Figure 2 EDF example At time t=0 an event occurs that trigger P1. P1 has the earliest deadline, since it is the only process that is ready to run. At time t=30 another event triggers P2. The scheduler compares the deadlines for P1 and P2 and realizes that P1 has the earliest deadline, so this process continues to run. At time t=40 P1 is finished and the scheduler schedule P2 to run, since this is the only task that is ready to run (and thereby has the earliest deadline). At time t=60 an event triggers P3. The scheduler realizes that P3 has the earliest deadline, so P2 will be preemptied and P3 will run instead. When P3 is finished, P2 again is the one with the earliest deadline so P2 will run until it finished. All deadlines have been met. Just like SF, EDF can also run as non pre-emptive. 4.2 Fixed Priority Scheduling In fixed priority scheduling, one associates every task/process/thread with a priority-number, according to some algorithm. When a thread is released to run, or a thread just is completed, the scheduler compares the priorities of all threads that are ready-to-run including the one that is running right now. If there is a thread that is ready to run with higher priority than the one occupying the CPU at the moment, the scheduler will pre-empt the CPU and let the thread with the highest priority run. When using fixed priority, you cannot be sure that you can schedule all sets of processes, even though the CPU s utilization is less than 100%. 7

9 The utilization of the CPU is calculated by the formula: U = i ti p i where t i is the CPU-time the process i needs every time it has to run, and p i is the period-time for process i. To be certain that you can schedule a set of processes with the optimal fixedpriority assignment algorithm, the following relation must be fulfilled: 1 n U < n * 2 1 [10] n is the number of processes to be scheduled. When n gets large, this expression is close to ln( 2). This means that if you have a lot of processes to be scheduled, the maximum utilization for the CPU is ~69.3% if you want to be certain that you can schedule them so that all deadlines are met. 4.3 Rate Monotonic Algorithm Rate Monotonic Algorithm (RMA) is a way to assign priorities and the use fixed priority scheduling with pre-emption, as described above. The priority assigned to a process depends on the periodicity of the task. Shorter period gives a higher priority, and vice versa. There are a few requirements on the processes to be able to use this algorithm. First of all, the CPU-time a process needs when it runs must be same every time it runs. It is also assumed that a task s deadline is the same as the end of a period. RMA is an optimal scheduling algorithm. In this case, optimal means that if a set of tasks cannot be scheduled by RMA, then no other fixed priority-algorithm can do the job. [9] Note that the relation for the utilization still must be fulfilled to be certain that a set of tasks is possible to schedule. 4.4 First In First Out First in first out (FIFO) also known as First Come First Serve (FCFS) is a relatively simple algorithm. There is a queue for each processor. Each time a process enters it will be put last in the queue for the process. The processor then picks the first process in the queue and lets it be run until completion. FIFO is no algorithm of good use in a Real-time system since it does not care about the running time or deadline of a process. A process with short running time and an early deadline runs a high risk of missing its deadline. 4.5 Minimum Slack Time First Minimum Slack Time First (MS) can in short be described as a mix of EDF and RR. Each process is given a value. The process with the lowest value will be the process that is run. The value is that of the time which would be left to deadline if the whole process (or what is currently left of the process) was executed at once and uninterrupted. It is easier to illustrate with a formula. S = ( D T ) P S : The value described above, called slack. D : The time of the deadline from when the process was initiated. If the process is periodic is the period time. T : The current time counted from the time when the process was initiated. D 8

10 P : The time which the process needs to run to be finished. MS works similar to the EDF but when processes have the same slack value the processes will take turns due to the process being run will not have its slack value decreased when running. [11] 4.6 Shortest Processing Time First The Shortest Processing Time First (SF) is a rather self describing algorithm. The processes to be scheduled are sorted so that the process with the shortest processing time will be handled first and the process with the longest processing time last. SF can be both preemptive and non pre-emptive. In the pre-emptive case assuming there is a process running which have 8 time units left to run. In the queue there are two more processes, one which takes 12 time units and one which takes 17 time units. If a new process with 6 time units running time comes in at that time, it will kick the first process, which had 8 time units left, returning it to the first spot in the queue. In the non pre-emptive case, the 6 time units long process will instead be placed first in the queue and be run when the 8 time unit long process is completed. 4.7 Round Robin Since it is not taking any notice about the current time left of a process or when the deadline is, the Round Robin (RR) algorithm is not really an algorithm which can be counted as an algorithm used in Real-time. RR is a simple algorithm which together with FIFO is the most used algorithm in non Real-time systems. RR gives each process a certain amount of time to be run, after that it kicks that process out and puts it last in the line and the next process in line gets it is time. Each process gets the same amount of time. 4.8 Time Sharing In the Time Sharing (TS) algorithm, each thread is given a priority just like in FP. The priority is then modified on the basis on how much of the processors time which have been used for the process. To put it simple it is a mix of FP and Round Robin. Regularly threads are rescheduled and the initial priority given to each thread is modified by a value dependant of the ratio the thread has been in the processor. 9

11 5 Discussion 5.1 Algorithms In a quick analysis of the above described algorithms two can easily be distinguished as algorithms not as advanced as the others. First In First Out and Round Robin do not base their scheduling on other threads, priorities or deadlines. There is no possibility to predict how long it will take for a thread to be finished. That is since the time is dependant on the workload of the processor which is not desirable in a hard real-time system. In a soft real-time system it might work but they are better suited for a GPOS, for example the ordinary Linux kernel in RTLinux, where the same demands for a thread to be finish at a specific time exists. Both algorithms can be used in RT-Mach and in the Linux kernel. Another algorithm which can also cause problems in a real-time system is Fixed Priority. The big problem with FP is that a thread with low priority has the risk of being locked out of the processor for a very long time and misses its deadline due to threads with higher priority always getting access to the processor. In its simplest form, the algorithm it is not good for a real-time system. To only be able to use 69 % of the processor capacity is a noticeable deterioration. The only advantage with the algorithm is that it is simple to implement and that its scheduling is very fast. In a soft real-time system it might work ok but there is still the problem that you can t use the processor more then 69 % to be sure that you do not lock out a thread from the processor. It can be a good solution in a system where you know the processor always have a work rate since there is a higher chance for a thread to get access to the processor in time. An improvement of the algorithm is to use aging, but it is only the base version which is used in RT-Mach, RTLinux does not use FP. In aging when a process runs its priority decreases. That will make threads with lower priority a higher chance of getting access to the processor. This helps to some degree but it does not help against many new threads with high priority. Another way to solve the problem is to use the algorithm Time Sharing which is one of the algorithms used in RT-Mach. It is a lot better algorithm to use in a real-time system than the algorithms discussed above. It runs a considerably less risk of locking a thread out of the processor. Because of the priority modifier there is a guarantee that a thread with low priority will get access to the processor which is not a case in FP if the processor is used more then 69%. The backside of the algorithm is that thread with higher priority risk missing its deadline due to being forced to leave the processor for threads with lower priority. It is mostly when high priority threads with a long work time have a relatively short amount of time left to deadline. The algorithm is working ok in both hard and soft real-time systems and can also work in a GPOS as well, but is in that case rather superfluous. The Shortest Processing Time First algorithm can be said to be a special case of FP and is neither better nor worse then FP. Therefore SF should be used just like FP. That is rarely or only if it is know that the workload is low on a real-time system. On a non real-time system it can be of about the same use as FP. The algorithms Earliest Deadline First (EDF) and Minimum Slack Time First (MS) can be seen as development of FP. In EDF the priority is set based on the time left to deadline. In MS it is set based on the difference between the time left to deadline and the time left for the thread before it is finished. The biggest difference is that EDF and MS take in calculation the deadline and in that way minimize the risk of a process missing its deadline. They can be hazardous though if the programmer is not paying attention. If the programmer sets the deadline of a process so that the processing time is longer than the time to deadline it can cause a domino effect if the system is high loaded. That is worse than only one missed deadline. When a process misses its deadline its run to long so that the next thread to be run 10

12 do not have enough to make its deadline and so on for the next thread after that. EDF and MS are good algorithms for real-time systems but they are more complicated algorithms to implement and the scheduling takes a longer to complete then it does in FP. EDF and MS also demands that the programmer knows what he is doing. Rate Monotonic Algorithm is just like EDF and MS time demanding to schedule. It is also only working 100% efficiently with periodic tasks. But with periodic tasks it is optimal so no other FP-algorithm can be run better. 5.2 Priority Inversion Handling Unfortunately we didn t find any information about how RTMach deals with the priority inversion-problem. In RTLinux there is support for a common solution to the problem; Priority inheritance. But FSMLabs, the company developing RTLinuxPro, does not recommend using this solution. FSMLabs has found that analysis of code is the best means of avoiding it. Based on internal and external experience, it follows that if the programmer does not know what resources the code might or might not hold at a given point, the chance of there being potential dangerous situations is very high. [2] They also point out that when using priority inheritance, it is very easy to end up in situations where a high prioritized process is blocked by low-prioritized processes that temporarily have gained a higher priority through priority inheritance. This causes the system to loose its deterministic characteristics and therefore should not be considered a hard real-time system. Consider an example where a high prioritized process is waiting for a mutex locked by a lowprioritized process. This low-prioritized process will then get promoted to a higher priority than the high priority-process. Now say that the low-prioritized process is waiting for a mutex from an even lower prioritized process, then this process will be given an even higher priority etc. At the end, the process that first had the highest priority will be far from highest prioritized, which can be quite serious. The system has lost its hard real-time property because you don t know how long this highest-priority process has to wait, it depends on the situation. To counteract this, RTLinuxPro is armed with a feature called priority ceiling protocol, in which you adjust the highest priority a process can be allotted by priority inheritance. We regard that FSMLabs can have a point in their statement. To solve the priority inversionproblem with inheritance can lead to that the problem just gets harder to find when it occurring, since its going so much deeper into the system. It might also be harder to localize the problem in the test stage of the system. If you not are using inheritance, it can be easier to find possible problems already in the stage of the system, and then solve in a better and more permanent way. 11

13 6 Conclusion We have found that the differences in scheduling between RTLinux and RTMach aren t so big. RTMach can easily use the same algorithms as RTLinux uses. RTLinux can relatively simple be extended by more algorithms whenever you need it since RTLinux consist of modules and RTLinuxFree is open-source software. In default there is, as can be easily read above, greater freedom of choice in RTMach. Both RTLinux and RTMach contain advanced tools to analyze the scheduler to see how well it is performing. One advantage with RTLinux is that the RTCore supports the POSIX-standard, so the programmer does not have to learn a completely new operating system and API. RTMach has not the same support, but there is a lot of similarity with earlier versions of Mach. But RTMach has an advantage over RTLinux by its support for multiprocessor systems. From a scheduling perspective, there makes no big difference which RTOS you choose. Other factors, such as which platform and developing environment you are using, has greater meanings. If you are developing multiprocessor system it can be worth looking at RTMach even if you have great experience of Linux. 12

14 7 References [1] Victor Yodaiken, The RTLinux Manifesto, [2] FSMLabs, Real-time Programming in RTCore, [3] CMU CS Project Mach Home Page, x [4] Real-Time Mach (RT-Mach) NTT Release Home Page [5] Hideyuki Tokuda, Tatsuo Nakajima, Prithvi Rao, Real-Time Mach: Towards a Predictable Real-Time System ftp://ftp.cs.cmu.edu/afs/cs/project/mach/public/doc/published/rtm.ps [6] David B. Golub, Operating System Support for Coexistence of Real-Time and Conventional Scheduling [7] Martin Naedele, A Survey of Real_Time Scheduling Tools [8] Real-Time Mach RK98 User Reference Manual [9] Silberschatz, Galvin and Gagne, Operating System Concepts, 7th ed., John Wiley & Sons, [10] David Stewart and Michael Barr, Introduction to Rate Monotonic Scheduling, [11] Operations Management -- Focusing On Quality & Competitivenes [12] Lecture slides TDDB72, [13] Lecture slides TSEA45, 13