Scheduling

SCHEDULING
EMBEDDED SYSTEMS PROGRAMMING
Authors: Date: File: Version:
Georg Brunnhofer/Thomas Platzer/Andreas Wallner 24 August 2012 Scheduling_V12.docx 1.2
Content
1 1.1 1.2 1.3 1.4 1.5 2 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8
Introduction Basics about scheduling Task, Process and Threads What is a Kernel? Basic principle of scheduling Task behavior (policy)[1] When to schedule When is scheduling needed? [1] Time slices Context switching States of execution Task priority Categories of Scheduling [1] Scheduling Algorithm Goals [1] Scheduling algorithms [1]
2.8.1 2.8.2 Scheduling algorithms in batch systems Scheduling algorithms in interactive systems
1-1 1-1 1-1 1-2 1-3 1-3 2-1 2-1 2-2 2-2 2-5 2-7 2-8 2-9 2-10
2-10 2-10
3 3.1 3.2 3.3 3.4 3.5 3.6 3.7 4
Real time systems Rate Monotonic Scheduling Deadline Monotonic Scheduling Earliest Deadline First Least Slack Time Priority inversion Transient overloads Scheduling vs. Dispatching Literature
3-1 3-1 3-3 3-3 3-4 3-4 3-5 3-5 4-1
Georg Brunnhofer/Thomas Platzer/Andreas Wallner Version 1.2, 08.11.2011
Introduction
1.1
Basics about scheduling
In multitasking computer systems there are multiple tasks or threads (smallest units of a task that can be scheduled see chapter 1.2 for sake of simplicity, the term task is used in this document) competing for the CPU at the same time. This situation occurs whenever two or more tasks are ready at the same time. If the amount of available CPUs is less than the amount of tasks a choice has to be made which task to run next. The part of the operating system which makes this choice is called a scheduler and the scheduling algorithm. A scheduler interleaves simultaneously executed tasks and, thus, represents the basis of all multitasking operating systems. This arrangement of tasks allows the introduction of multiprocessor systems in the first place. Scheduling, too, enables tasks to be shifted into background while new ones pop up that need to be executed. These shifted tasks are not runable although they are in memory. They use kernels instead that wait for events (like keyboard entry, network data, certain timeout) to appear. An operating system, for instance, may have 100 tasks in memory but only one in run able state. The scheduler is mainly concerned with: Throughput number of tasks that complete their execution per time unit Latency o Turnaround total time between the submission of a task and its completion o Response Time time from task submission until its first response Fairness/ Waiting time - appropriate CPU time for each task (as this is handled via priorities)
Basically, there are two different types of scheduling cooperative scheduling (or multitasking) and preemptive scheduling.
1.2
Task, Process and Threads
Before we start talking about processes and threads we want to clarify the terms task, "process" and "thread". Therefore we can state that a process is just an executing program, together with the values of
Georg Brunnhofer/Thomas Platzer/Andreas Wallner Version 1.2, 24 August 2012
1-1
Error! Use the Home tab to apply berschrift 1 to the text that you want to appear here. Error! Use the Home tab to apply berschrift 1 to the text that you
its program counter, variables, registers, memory and required device resources. A conceptual model is that multiple processes run in parallel. The CPU switches then between the processes. A thread instead is the unit of scheduling for the OS. One task can be comprised of many threads. Threads within a task share memory. When a thread issues a system call that can't immediately complete, it blocks and the OS runs another thread. A task can be understood as the more generalizing term for task and thread since multitasking refers to tasks as well as to threads.
1.3
What is a Kernel?
The kernel is the main component of operating systems. It is responsible to manage the systems resources and hence does the communication between software and hardware components. Those resources typically comprise: CPU Memory I/Os Objects such as semaphores, message queues, files
Figure 1.1: Connection of applications software and the hardware over the kernel
The kernel takes responsibility for:
1-2
decision at any time which of the running tasks should be allocated to the processor(s). The scheduler, as the heart of the kernel, provides the algorithms needed to determine which task executes when. providing memory space to every task and decide what to do when not enough memory is available allocating requests from tasks to perform I/O to an appropriate device
1.4
Basic principle of scheduling
The scheduler has to pick the right task to run and it has also to worry about making efficient use of the CPU because task switching takes some time. To start with, a switch from user mode to kernel mode has to be done. Then the context of the current task must be saved, including storing its registers (so they can be reloaded later). Next a new task is selected by running the scheduling algorithm. After that, the MMU (Memory Management Unit) must be reloaded with the context of the new task. Finally, the new task is started. In addition to that, the task switch usually invalidates the entire memory cache, forcing it to be dynamically reloaded from the main memory twice (upon entering the kernel and upon leaving it). All in all, doing too many task switches per second can chew up a substantial amount of CPU time, so caution is advised.
1.5
Task behavior (policy) (1)
The policy explains the behavior of the scheduler. It schedules when which task shall be running. Policy is also responsible to use the CPU optimal regarding processing time. All tasks alternate bursts of computing with disk or I/O requests. The CPU runs for some time without stopping and has then to wait when a system call is made to read or write to a file. There are two different types of tasks to distinguish: I/O-bound tasks which are waiting for I/O requests most of the time and, thus, giving other tasks the advantage. Those I/O- bound tasks are run able quite often but only for short time periods. Compute bound tasks spend most time with executing code. These tasks tend to run until they get preempted since there are rarely I/O request to be waiting for. Providing a constant processing flow, compute- bound tasks do not need to be executed often as they are not I/O driven. So, scheduling can be optimized when providing compute-bound tasks with longer CPU times and I/O-bound tasks with quick and short disruptions to issue its resource request. If there are more I/Obound tasks than compute-bound, the occupation of the CPU decreases. Both variants are not necessarily mutually exclusive e.g.: word processor
1-3
A word processor patiently waits for keyboard actions and suddenly demands CPU resources for reasons of the spell checker. The scheduler policy in general has to fulfill two opposing tasks - low latency and high data throughput. Therefore, scheduling algorithms are utilized which choose the most worthy task to be executed.
long CPU burst CPU bound process
waiting for I/O I/O bound process
short CPU burst
Figure 1.2: Process behaviour according to (1)
1-4
When to schedule
2.1
When is scheduling needed? (1)

task. Since both tasks are in ready state the scheduling algorithm can decide to go either way. So it can choose parent first and child next or vice versa.
1. When a new task is created a decision needs to be made whether to run the parent task or the child
2. A scheduling task has also to be made when a task exits. The algorithm has to choose a ready task or run an idle task. 3. Third when a task blocks on I/O, on a semaphore, or for some other reason another task has to be selected to run. Sometimes the reason for blocking may play a role for the choice. 4. Fourth when an I/O interrupt occurs, a scheduling decision has to be done. Special care has to be taken with clock interrupts. A nonpreemptive (or cooperative) interrupt scheduling algorithm picks a task to run and then lets it run until it blocks (either on I/O or waiting for another task) or until it releases the CPU. Hence, the time until the task quits is up to the executed task itself. This procedure is called yielding. Even if it runs for hours it cannot be forcibly suspended by the OS. Quite to the contrary, the currently executed tasks are expected to regularly suspend its execution. According to this, no scheduling decisions are done during clock interrupts. This approach comprises many disadvantages: The scheduler cannot take global decisions about how long tasks should run The CPU may be occupied by tasks longer than desired from the user A task running in endless loop forces the whole system to a dead halt In contrast, a preemptive scheduling algorithm picks a task and lets it run for a maximum time. This time is predetermined and is called time slice. The time slice allocates certain portions of CPU time to each executable task. A still running task reaching the end of the time interval is suspended and the scheduler picks another task to execute (if available). As the scheduler manages the time slices, global decisions referring the system can be taken. The biggest advantage is that the CPU is never hijacked by a single task. It also allows the system to rapidly deal with important external events like incoming data, which might require the immediate attention of one or another task. Preemptive scheduling requires a clock interrupt at the end of the time interval or giving control of the CPU to the scheduler. If no clock is available, nonpreemptive scheduling is the only option.
2-1
swap in
Paritally executed Swapped-out processes
swap out
in
ready queue
CPU
out
CPU
I/O waiting queues

Figure 2.1: Process flow chart (2)
2.2
Time slices
A time slice is a numerical value of how long a task may run before it is preempted. A standard time slice has to be allocated by the scheduling policy. To long time slices imply bad interactive performance of the system and hence worsen the ability of executing tasks quasi simultaneously. On the contrary, too short time slices imply a considerably waste of processor time due to permanent swapping of tasks (see chapter 2.3 Context- switching). I/O bound tasks do not require long time slices but need to be executed more often. Whereas compute bound demand longer time slices to keep e.g. their cache contents updated.
2.3
Context switching
A context switch occurs when the scheduler switches from one task to another. It is the storing and restoring of the state (context) of a CPU so that execution can be resumed from the same point at a later time. Each task has its own context. Switching from one task to another requires a certain amount of time for doing administration saving and loading registers and memory maps. This time is called context switch time. The switching itself is performed by an associated module called dispatcher. Every time a new task is created, the kernel also creates an associated task control block TCB. TCBs are system data structures that the kernel uses to maintain task- specific information. They contain everything a kernel needs to know about a particular task. When a task is running its context is highly dynamic. However, when the task is not running its context is frozen within the TCB, to be restored the next time the task runs.
2-2
Figure 2.2: context switching (3)
When the kernels scheduler determines that it needs to stop a running task 1 and start running task 2, it takes the following steps: 1. The kernel saves task 1s context information in its task control block TCB. 2. It loads task 2s context information from its TCB, which becomes the current thread of execution. 3. The context of task 1 is frozen while task 2 executes. But if the scheduler needs to run task 1 again, task 1 continuous from where it left off just before the context switch. Since frequent context switching can incur unnecessary performance overhead the kernel has another task to take into account.
2-3
in
ready queue
CPU
I/O
I/O queue
I/O request
time slice expired
child executes
fork a child
interrupt occurs
Figure 2.3: Scheduling decisions (2)
wait for an interrupt
The figure above shows the reasons for scheduling in a preemptive system.
2-4
2.4
States of execution
Running state: The task is running as it had the highest priority to be chosen by the scheduler. Only one task can be in a running state (in a single- processor system).
When a task is moved to the running state, the processor loads its registers with the tasks context. If a higher prioritized task demands the CPU the currently executed task is put to the ready state and the requesting task takes over its place. Ready state: When a task is first created it is made ready to run. The kernel puts it in ready state. That does not yet imply that the task is already permitted to run. In the ready state the new task competes with all other tasks for the processors execution time.
Blocking state: Non run able tasks are held in blocking state. This is essential for the scheduler in order not to execute tasks that dont need to be run. Tasks may go into blocking state for several reasons: The running task has requested a resource that is not yet available. It has requested to wait until some event occurs. This event could be a certain time period, more data from an I/O procedure, or another hardware event. It has delayed itself for some duration
Example: a task invokes a read() function and has to wait for the data to be read from the hard disk
When a task becomes unblocked it is put back to the ready state list waiting for execution. However, if the unblocked task has the highest priority it moves to the running state directly. The currently executed is then preempted and put to the ready state as previously described.
2-5
Figure 2.4: ready state list in 5 steps (3)
Lets go through the example in figure 2.3: 1. In the first step the ready state list contains 5 tasks to be executed, which are sorted by its priority (lowest number means highest priority) 2. Because task 1 has the highest priority, it is the first list entry ready to run. The kernel moves it from the ready state to the running state. The remaining tasks are then shifted once further. 3. In the 3rd step, assuming that task 1 makes a blocking call the next list entry is executed. A blocking call for task 1 means that it is moved to blocking state. 4. Task 3 is put running as the previous task also made a blocking call. 5. As task 3 runs, the resource that task 2 requested became free. Hence, the kernel returns task 2 to the ready state and sorts it according to its priority. Task 3 continuous as the currently running task since the priority is at least the same.
2-6
2.5
Task priority
The most common type of scheduling algorithms is the priority based scheduling. Tasks are classified according its required processor time. Higher prioritized tasks come before lower ones. Equal priorities are handled each after the other which is known as round robin. Some operating systems (like Linux) provide higher prioritized tasks even with longer time slices. Priorities may be modified by either the user or the systems itself in order to vary or accommodate the behavior of the scheduler. Linux, for instance, is built upon the idea of modifiable priority allocation which is named dynamic priority based scheduling. Priorities are increased or decreased dynamically in order to fulfill the desired scheduling requirements. Example: A task spending more time with waiting for an I/O request is apparently I/O- bounded. As a consequence, the priority is increased dynamically. Tasks which frequently demand its entire time slice is compute- bound and, thus, get a lower priority allocated.
Another very important aspect of prioritization is to take real time applications and tasks into account and meet their needs.
lower priority
or interactivity
higher priority
or interactivity
Minimum Time slice
default
Figure 2.5: Priority to time slice (3)
Maximum Time slice
Example: A system has two runnable tasks, a text editor and a video- encoder. The text editor is I/O bound since it mostly waits for keyboard input of the user (regardless of how fast the user can type). Independently, the user expects immediate response of the editor.
2-7
In contrast, the video- encoder is compute bound and demands much CPU resources (up to 100%) on applying its video codec algorithm to processe the raw data. In this scheduling scenario the text editor will get a higher priority and a longer time slice allocated as the text editor is an interactive program. Furthermore, the video- encoder may be preempted by the text editor due to the editors higher priority. The video- encoder will indeed be at a disadvantage but will only be interrupted for a short time and have the remaining time available. The performance of both applications is, thus, optimized.
2.6
Categories of Scheduling (1)
Different applications in different areas need different kinds of operation systems as they have different goals; therefore we introduce three different types of scheduling algorithms. One can distinguish 1. Batch or off-line (since there is no user interaction) 2. Interactive 3. Real Time
ad 1.: Batch systems are widespread in the business world (at banks) claiming processing and other periodic tasks. There are no users impatiently waiting at their terminals for a quick response to a short request. Consequently long time periods for each task are often acceptable. This approach reduces task switches and thus improves performance. The scheduling algorithms can be both, nonpreemptive or preemptive. ad2.: Environments with interactive users, preemption is essential to keep one task from hogging the CPU and denying service to others. Even if no task intentionally ran forever, one task might shut out all the others indefinitely due to a program bug. Preemption is needed to prevent this behavior. Servers also fall in this category, since they normally serve multiple (remote) users, all of whom are in a big hurry. ad3.: In real-time system preemption is sometimes not needed because the tasks may not run for long periods. Real-time systems mostly run specialized tasks only. So there is quite a difference to interactive systems. These category of scheduling algorithms are especially designed to meet deadlines during their operations.
2-8
2.7
Scheduling Algorithm Goals (1)
In all systems the algorithms goals should be to achieve fairness, which means giving all tasks a fair share of the CPU's time. Another important point is the policy enforcement which proves that the stated policy is carried out. Additionally there should be a great remark on the balance which means that all parts of the systems are kept busy. For Batch systems it can be stated that the throughput (maximize jobs per hour), the turnaround time (minimized time between submission and termination) and the CPU utilization are the most important goals. In interactive systems the response time (respond to requests as fast as possible) and the proportionality, which means that the user's expectations are met, are the most important issues. For real-time systems deadlines should be met. This means that tasks have to be run timely. Dependent on the algorithm some data can be lost Additionally the system should be predictable. One important goal is to keep all the parts of the system busy. For example it is not good to do all the CPU bound jobs first and then to do all the I/O bound jobs because parts of the system are idle during all operational steps. It is better to keep all parts busy to achieve the best performance. By this the throughput of the system is increased. The throughput is the number of jobs which are done per one time unit (e.g. per hour). The turnaround time is the statistically average time from the moment that a batch job is submitted until the moment it is completed. It measures how long the average user has to wait for the output. An algorithm that maximizes throughput is not necessarily an algorithm that reduces turnaround time since a lot of short period tasks brings along a high throughput but a terrible turnaround time for the longer period tasks. For interactive systems another goal is pretty important, the response time that is, the time between issuing a command and getting the result. For example on a computer where background tasks are running (reading and storing emails from the network), a user request to start a program or open a file should take precedence over the background work. Having all interactive requests go first will be perceived as a good service. Another important goal in interactive systems is proportionality. This means that user's have an expectation how long things should take. If they think that the task is very complex, they accept to wait a bit longer. If users have to wait for tasks they perceive as simple but take a bit longer, they get irrigated. The scheduler can only do something against these delays if the choice of the task order is good.
2-9
2.8
2.8.1
Scheduling algorithms (1)

Scheduling algorithms in batch systems
First-come first-serve Probably the simplest of all scheduling algorithms is nonpreemptive first-come-first-serve. Tasks are assigned to the CPU in the order they request it. There is a single queue of ready tasks. When the first job enters the CPU, it is started and runs as long it wants to. When other jobs come in, they are put onto the end of the queue. The algorithm is easy to understand and easy to program but there is a big disadvantage. If there are long compute-bound tasks, all I/O-bound tasks are blocked. After the compute-bound task has finished the I/O task starts running and starts e.g. its disk read. So it takes the I/O-bound task a lot longer to finish than if the algorithm would be preemptive. Shortest job first Shortest job first is a nonpreemptive batch algorithm that assumes that run times are known in advance. When several equally important jobs are sitting in the input queue and waiting to be started, the scheduler picks the shortest job first. This is only optimal if all the jobs are available simultaneously. Shortest remaining time next A preemptive version of shortest job first is shortest remaining time next. The algorithm picks the job with the shortest remaining time. Therefore the run time has to be known in advance. When a new job arrives the remaining time to compute the task is compared to the current tasks' remaining run time. The job which needs the least amount of time to finish is then chosen. This scheme allows new jobs to get a good service.
2.8.2
Scheduling algorithms in interactive systems
Round robin scheduling One of the oldest, simplest, fairest and most widely used algorithms is round robin. Each task is assigned a time interval called quantum. The task is allowed to run in its quantum of time. If the task is not able to finish in its quantum the CPU is preempted and given to another task which then gets again a quantum of time. If a task blocks or finishes before the quantum of time is over, the CPU switching is done before the quantum is over. Round robin is easy to implement because all the scheduler has to do is to maintain a list of runnable tasks. When a task uses up its quantum it is put to the end of the list. Important is, that the quantum of time is not too short or the overhead (CPU switching) will get higher than the execution time. To sum up it can be said that a too short time quantum causes too many CPU switches and lowers the
2-10
efficiency, but setting it too long may cause a poor response time to short interactive requests. A quantum of 20-50 ms is often a reasonable compromise. Priority Scheduling Whereas round robin scheduling makes the assumption that every task is equally important we now introduce a kind of hierarchy to the tasks. The basic idea is straightforward: each task is assigned a priority, and the runnable task with the highest priority is allowed to run. To prevent high-priority tasks from running indefinitely, the scheduler may decrease the priority of the currently running tasks at some clock tick (i. e. in each clock interrupt). If this action causes its priority to drop below that of the next highest priority, a task switch occurs. When this quantum is used up, the next highest priority task is given a chance to run. This prevents tasks from starving. It is often convenient to group tasks into priority classes and use priority scheduling among the classes but round-robin scheduling within each class. First all tasks in the highest priority class are handled roundrobin. If the highest class is empty the next lower class is tasks round-robin. The problem with this algorithm is that lowest priorities may not serviced often enough.
Another Algorithms In Guaranteed Scheduling each task gets the same amount, let's say a guaranteed amount of time. Guaranteed scheduling is mostly used for multi user systems. Lottery Scheduling makes no promises to the users. Basic idea is giving lottery tickets to tasks. Whenever a scheduling decision has to be made a lottery ticket is chosen randomly. More important tasks can be given extra tickets to increase their chance of winning.
2-11
Real time systems
The target for RT scheduling algorithms is that the deadlines for all real-time tasks are met. If a deadline cannot be met they should optimize for minimum lateness. Another feature of RT algorithms is that there exist ways to mathematically prove that a specific set of tasks is schedulable, meaning that all deadlines of the tasks can be met. Preemption is a mostly prerequisite, otherwise the algorithms won't work. When checking for schedulability we have to distinguish between periodic and aperiodic events we have to react to. Aperiodic events are usually dealt with as sporadic events. This means that an event can only be triggered a certain time after the last event of the same type was triggered. This way an event should only be triggered after the last event of the same type is processed. If aperiodic events are not sporadic, one generally has to use algorithms with dynamic priorities. Clock driven scheduling implementations like timing wheels etc. fall under the category of static scheduling algorithms without priorities. They are only feasible if everything is known at design time of the system; no aperiodic events can happen and are inflexible in the case of e.g. adding another task. It is mostly done on a non-preemptive basis. The compliance with deadlines has to be proven for the complete code. There is no safeguard for the case that one task is programmed incorrectly and e.g. does not release the CPU, so an unimportant non-realtime task can prevent the operation of the complete system. A round robin scheduler gives each task a timeslice of a certain (constant) size. It does not implement any priorities. It is mostly used in best-effort packet switching such as in Ethernet switches or routers. It is a fair scheduling algorithm, but it is not optimized for anything beyond that.
3.1
Rate Monotonic Scheduling
The rate monotonic scheduling algorithm is an algorithm for periodic tasks with static priorities. These priorities are assigned to be inversely proportional to the period of the task. The shorter the period, the higher is the priority. It is assumed that the period of the task is equal to its deadline. It is also assumed that context switches are free and that single tasks can't block each other (by e.g. requiring access to the same hardware) The Algorithm is very easy: the task with the highest priority being ready at the moment is scheduled. Using those rules we can prove the schedulability of a set of tasks. We can also calculate a worst case upper bound (called for the possible utilization of the CPU. ( )
3-1
(n being the number of tasks, upper bound is ln(2) ~ 69.3%). We can be sure that our set of tasks is schedulable if the needed CPU utilization is below this boundary. On the other hand this does not mean that a set of tasks is not schedulable if its utilization is above this boundary. In the special case that periods of the task set are harmonic (every period is an integer multiple of all smaller periods), can the utilization reach 100%. There also exist different formulas for systems that e.g. specify weaker prerequisites or systems that have to deal with sporadic events. Using mathematical models it can be shown that for the above premises, the rate monotonic scheduling is the optimal scheduling algorithm, meaning that a set of tasks that can't be scheduled using RMS can also not be scheduled with any other fixed-priority algorithm. Example: Two tasks t1 and t2 with periods T1=50ms and T2=100ms. The respective worst case execution times are C1=25ms and C2=40ms. CPU utilization is C/T, thus U1 = 50%, U2=40%. Complete utilization will be 90%. For this example, the upper bound for the CPU utilization is ( )
which is lower than the utilization we actually have. Even though this is the case, the example is still schedulable. As said before, the calculated maximum CPU utilization is a sufficient criteria to be met, not a necessary one.
Figure 3.1: Example for RMS scheduling (4) Case 1 with correct priorities, case 2 with swapped priorities
One problem for a system running RMS could be sporadic events that trigger tasks. These cannot be described by the algorithm because they do not have a period. Certain ways were proposed to deal with
3-2
sporadic tasks in RMS algorithms, for most of them we refer to the corresponding literature. One simple approach though is the usage of a periodic task which purpose is the handling of all incoming aperiodic/sporadic events. This can be sufficient if the rate of aperiodic events is low enough.
3.2
Deadline Monotonic Scheduling
One of the premises for the use of the RMS algorithm was that the period of a task is equal to its deadline. For that scenario RMS is the optimal static algorithm. If this is not the case, then the deadline monotonic scheduling algorithm is optimal. DMS is - like RMS - a scheduling algorithm with static priorities. The assignment of priorities in DMS is according to the deadline. Tasks with a shorter deadline are assigned higher priorities. All other premises for the RMS algorithm also apply to the DMS algorithm. The scheduling itself is again: The ready task with the lowest priority is executed. Like for RMS, there exist methods of calculating schedulability etc. but those would go beyond what is covered here. One advantage of DMS over RMS is that sporadic events can be handled easier, since the information the algorithm needs (the deadline) is known to the system. They can be treated like periodic tasks. For deadline = period, RMS and DMS yield the same result, but proofs for schedulability for RMS are easier than for DMS, therefore RMS is still a used alternative.
3.3
Earliest Deadline First
EDF is an algorithm that assigns priorities on a dynamic basis. The task with the earliest absolute deadline will get the highest priority. The ready task with the highest priority is scheduled. Ties are decided randomly. EDF is optimal in the sense that it can achieve utilizations up to 100% without special requirements. Offsets of task starts etc. are not relevant. While having this big advantage, it has certain disadvantages: less predictable then RMS/DMS less controllable: to reduce the response time for a task in RMS we can simply increase its priority. There is no such thing in EDF. more implementation overhead: RMS can be optimized to be O(1) for queueing, EDF is at best O(log(n)) in case of an overload it may happen that all tasks will miss their deadline response time calculations are very hard to do and depend on all parameters of all tasks
3-3
3.4
Least Slack Time
The slack time is the timespan after finishing work to the deadline. It can be calculated calculating the remaining execution time and subtracting that from the time to the deadline. The task with the lowest remaining execution time (slack time) gets the highest priority. Again the ready task with the highest priority is scheduled.
LST is complex compared to the other algorithms, since it requires already spent execution times as well as average or peak execution times of tasks as input. To have a schedulability guarantee one has to use worst-case values which may lead to poor CPU utilization. LST can - like EDF - be used up to 100% CPU utilization. Since no a-priori assumptions are made, it is very well suited for serving systems with a high amount of aperiodic events, but it suffers from many of the problems that EDF suffers from, especially the undefined behavior since scheduling is dynamic. Of the here described algorithms it is the one with the most overhead, and is the most complicated to prove.
3.5
Priority inversion
One problem that is common to all the described algorithms can occur if tasks are synchronized to each other using inter-task communication methods or e.g. by requiring the same hardware. A low priority task my block a resource that a high priority task that is currently scheduled needs to finish. The high priority task has to wait until the low priority task releases the resource, but the low priority task is never scheduled, therefore it cant finish its operation. This is called priority inversion.
Three basic methods can be used to deal with priority inversion: One can prohibit preemption while a resource is held or the task is in a critical section. As long as those sections are kept short this might be acceptable. One can prevent priority inversion altogether if no task is allowed to acquire a resource or enter a critical section if the possibility exists that a higher priority task might be blocked. This can only be done if there are only periodic tasks for which the execution times are known. A task may only acquire a resource / enter a critical section if there is enough time left to release/exit it again before a higher level task starts again. This might pose the problem that idle times could be introduced into the system. Priority inheritance might also be used to deal with priority inversion. In this scheme the priority of a low priority task is increased to that of a high level task which execution the low level task is blocking. The ceiling protocol. This is an enhanced version of priority inheritance and too extensive to be covered in this document.
3-4
3.6
Transient overloads
Also interesting is the behavior of the algorithms when transient overloads occur. Transient overloads are short overloads of the system. Such overloads could happen e.g. because of bursts of aperiodic events. Both of the dynamic priority algorithms handle such overloads very poorly and might end up in missing the deadlines for all tasks. The static priority algorithms suffer one problem: They might miss deadlines for important hard-realtime tasks for the sake of higher priority soft-realtime tasks. This problem stems from the nature of the assigned priority which has no connection to the importance of a task. There are many ways to deal with this problem, but three simple solutions shall be described here: Period transformation: A task with a high importance is split into multiple instances that are to be executed after each other. They should be split in a way that the resulting smaller tasks get higher priorities that match the importance of the task. Dynamic change of priorities in the case of an overload: In the case of an overload the scheduler switches to a different set of priorities that matches the importance of the tasks. Design the system in a way that transient overloads cant occur. This would e.g. be the case when no aperiodic events are allowed. The first two approaches increase the chances/guarantee that tasks of high importance but e.g. a long period are scheduled instead of low importance tasks that have shorter periods.
3.7
Scheduling vs. Dispatching
Until now we only discussed scheduling algorithms. A typical scheduler is only the part that chooses which task to execute next. There is also a part that has to do the switches between tasks (context switches), which is called the dispatcher. Dispatchers can have different complexity. The simplest dispatcher is one for cooperative algorithms, where the dispatcher only has to call the next task, it will return when it finished its work for this call. Since there cant be two tasks running semi-parallel we dont really need to switch between tasks. On a system with preemption the workload for the dispatcher is considerably higher. In principal the state of the processor has to be stored, another state loaded, if applicable a switch to user mode be done and control given to the switched to task. We will look at the dispatchers workload for two examples: a MSP430 system and a standard ARM system running Linux. MSP430 System As example we use the dispatcher from FreeRTOS for MSP430 CPUs. The dispatcher/scheduler will most likely be called from a timer interrupt: all registers are pushed onto the stack
3-5
the current stack pointer is saved into the task specific struct the correct stack pointer for the new task is loaded all registers are popped from the stack, the power down bits of the status register are masked For such a small CPU a context switch is very simple. No switch to usermode etc. is needed since the CPU has no protection modes. Nor does any MMU/MPU need servicing. ARM System Short version of Linux dispatcher without using the FCSE (Fast context switch extension) which is not up to date but better from an educational standpoint. The routine is called as a timer interrupt. switch to supervisor mode (to get access to the correct stack) push all other register, return address register and status registers load next task info pointer into a register (in succession called R13) load new TLB (translation lookaside buffer, the table storing mappings between virtual and physical memory) invalidate data cache and instruction cache load registers from structure pointed to by R13 load R13 switch to user mode return control to task This list has gotten shorter since the fast context switch extension for ARM was introduced. The way it is described here, it takes about 150 CPU cycles, and invalidate all caches.
3-6
Literature
1. Tanenbaum, Andrew S. Modern operating systems. Third Edition. Amsterdam : Pearson Education International, 2009. 2. Electrical and Computer Engineering Department, University of Toronto. Operating Systems Scheduling. [Online] 2007. http://www.eecg.toronto.edu/~jacobsen/os/2007s/scheduling.pdf. 3. Yao, Quing Li with Caroline. Real-Time Concepts for Embedded Systems. 2003. 4. Barr, Michael. EEETimes. [Online] February 2002. http://www.eetimes.com/discussion/beginner-scorner/4023927/Introduction-to-Rate-Monotonic-Scheduling . 5. Love, Robert. Linux-Kernel-Handbuch. s.l. : Addison-Wesley, 2005. 6. Audsley, Neil C. Deadline monotonic scheduling. Department of Computer science, University of New York. Heslington, York : s.n., September 1990. Paper. 7. Burns, A. Scheduling hard-realtime systems: a review. Software Engineering Journal. May 1991, pp. 116-128. 8. Systems, Scheduling Algorithms for Real-Time. Arezou Mohammadi and Selim G. Akl. School of Computing, Queen's University. Kingston, Ontario : s.n., July 15, 2005. Technical Report. 9. Gilles Chanteperdix, Richard Cochran. The ARM Fast Context Switch Extension for Linux. Xenomai, Omicron. Report.
4-1

Scheduling

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Scheduling

Загружено:

Авторское право:

Доступные форматы

SCHEDULING

EMBEDDED SYSTEMS PROGRAMMING

Authors: Date: File: Version:

Georg Brunnhofer/Thomas Platzer/Andreas Wallner 24 August 2012 Scheduling_V12.docx 1.2

3 3.1 3.2 3.3 3.4 3.5 3.6 3.7 4

3-1 3-1 3-3 3-3 3-4 3-4 3-5 3-5 4-1

Georg Brunnhofer/Thomas Platzer/Andreas Wallner Version 1.2, 08.11.2011

Basics about scheduling

Task, Process and Threads

Georg Brunnhofer/Thomas Platzer/Andreas Wallner Version 1.2, 24 August 2012

The kernel takes responsibility for:

Georg Brunnhofer/Thomas Platzer/Andreas Wallner Version 1.2, 24 August 2012

Basic principle of scheduling

Task behavior (policy) (1)

Georg Brunnhofer/Thomas Platzer/Andreas Wallner Version 1.2, 24 August 2012

waiting for I/O I/O bound process

short CPU burst

Figure 1.2: Process behaviour according to (1)

Georg Brunnhofer/Thomas Platzer/Andreas Wallner Version 1.2, 24 August 2012

When is scheduling needed? (1)

Georg Brunnhofer/Thomas Platzer/Andreas Wallner Version 1.2, 24 August 2012

Paritally executed Swapped-out processes

I/O waiting queues

Georg Brunnhofer/Thomas Platzer/Andreas Wallner Version 1.2, 24 August 2012

Figure 2.2: context switching (3)

Georg Brunnhofer/Thomas Platzer/Andreas Wallner Version 1.2, 24 August 2012

time slice expired

wait for an interrupt

Georg Brunnhofer/Thomas Platzer/Andreas Wallner Version 1.2, 24 August 2012

Georg Brunnhofer/Thomas Platzer/Andreas Wallner Version 1.2, 24 August 2012

Figure 2.4: ready state list in 5 steps (3)

Georg Brunnhofer/Thomas Platzer/Andreas Wallner Version 1.2, 24 August 2012

Minimum Time slice

Maximum Time slice

Georg Brunnhofer/Thomas Platzer/Andreas Wallner Version 1.2, 24 August 2012

Categories of Scheduling (1)

Georg Brunnhofer/Thomas Platzer/Andreas Wallner Version 1.2, 24 August 2012

Scheduling Algorithm Goals (1)

Georg Brunnhofer/Thomas Platzer/Andreas Wallner Version 1.2, 24 August 2012

Scheduling algorithms (1)

Scheduling algorithms in interactive systems

Georg Brunnhofer/Thomas Platzer/Andreas Wallner Version 1.2, 24 August 2012

Georg Brunnhofer/Thomas Platzer/Andreas Wallner Version 1.2, 24 August 2012

Real time systems

Rate Monotonic Scheduling

Georg Brunnhofer/Thomas Platzer/Andreas Wallner Version 1.2, 24 August 2012

Georg Brunnhofer/Thomas Platzer/Andreas Wallner Version 1.2, 24 August 2012

Deadline Monotonic Scheduling

Earliest Deadline First

Georg Brunnhofer/Thomas Platzer/Andreas Wallner Version 1.2, 24 August 2012

Least Slack Time

Georg Brunnhofer/Thomas Platzer/Andreas Wallner Version 1.2, 24 August 2012

Scheduling vs. Dispatching

Georg Brunnhofer/Thomas Platzer/Andreas Wallner Version 1.2, 24 August 2012

Georg Brunnhofer/Thomas Platzer/Andreas Wallner Version 1.2, 24 August 2012

Georg Brunnhofer/Thomas Platzer/Andreas Wallner Version 1.2, 24 August 2012

Вам также может понравиться