CPU Scheduling Preemptible and non-preemptible resources The resources handled by a multiprogramming operating system fall into two

classes.

Preemptible resources. Examples of these resources are processors and I/O channels. The operating system can take a preemptible resource away from a process and assign the same to some other process, and then may reassign it back later to the process. Non-preemptible resources. Once this kind of a resource is given to a process, the operating system cannot give the resource to any other process until the process gives it back. Examples of such resources are file space, printer, etc.

Thus a multiprogramming operating system must take allocation decisions (for non-preemptible resources) and scheduling decisions (for preemptible resources) in a fair and efficient manner. The allocation involves such decisions as to who gets what resources. In other words, given a set of requests for resources, which processes should be given which resources in order to make the most efficient use of the resources? This assumes more importance since the resources allocated are not easily preemptible. For preemptible resources, the scheduling decisions involve issues such as to who is going to get the free resource next and how long can they keep it. An extremely important preemptible resource is the processor. We discuss processor scheduling next. CPU Scheduling As discussed in the previous lecture notes, a process may be in any one of three states of execution (see figure below):

The state transition from ready state to run state (see figure below) is handled by the CPU scheduler.

Figure 1: The three states of execution

There are two parts to CPU scheduling normally referred to as the dispatching part and the scheduling part. The dispatcher part provides the basic mechanism for restoring the process status and transfers control of the CPU to the process (that is, make the process a running process). The scheduling part is a piece of operating system code that decides which process (among the many processes that are in the ready state) should get a free CPU next and how long it can use it. The processes that are in ready state are kept in a queue called the ready queue. When a CPU becomes

Figure 2: The dispatcher handles this transition

free, the CPU scheduler has to select a process from the ready queue and dispatch it. Note that a CPU, running a process, becomes free whenever the process goes through one of the following four state transitions: (1) Run to wait state (because of an I/O operation or wait for some event to finish.) (2) Run to ready state (because of a timer interrupt or a higher priority process wants CPU.) (3) Wait to ready state (because the event for which the process has been waiting has occurred.) (4) Run to terminate state (because the process execution is complete or it is terminated.)

The ready queue need not be a first in first out kind of a queue. When there are several processes in the ready queue that are runnable, how can we decide which process goes first? A scheduling policy attempts to achieve (optimize) a certain goal or an objective. Goals of Scheduling (objectives) Obviously any two distinct selection strategies will have different properties and would favor one set of processes over another. Many selection policies (therefore, many CPU scheduling schemes/algorithms) are possible. Which one to adapt depends on what we want to achieve or optimize in our situation. In order to compare the performance of scheduling strategies several criteria have been suggested.

Figure 3: The four state transitions that make a CPU free

CPU Utilization. Keep the CPU as busy as possible with user processes. Throughput. Maximize the number of jobs processed per unit time. Turnaround time. This is the interval from the time of submission of a processs to the time of its completion. That is the total time period for a process that transitions from the new state to terminate state. In general, the operating system or the CPU scheduler has no control over this duration. For example some processes that involve a lot of input/output operations will have a longer turnaround time as compared to short processes. So, instead of considering the turnaround time for just one process, we can consider the average turnaround time among several processes and try to minimize this average. Waiting time. During its lifetime, a process goes through the ready queue several times. Each time it arrives at the queue, it spends some time waiting to get dispatched. The sum of all times that a processs spends waiting in the ready queue is called the waiting time. We can consider minimizing the average waiting time. This is an important criterian and our choice of a CPU scheduling algorithm can affect this criterian directly. Response Time. The is the time it takes to dispatch a process after it has arrived in the ready queue. This is an extremely important criterian for real time systems and time shared systems that support interactive users. One would like to minimize the average response time.

Preemptive and non-preemptive scheduling A scheduling discipline is non preemptive if, once a process has been given the CPU, the CPU cannot be taken away from that process. In a preemptive scheduling discipline, we can take the CPU away from the process and put the processs back in the ready queue. See the transition labelled with number 2 in figure 3. This strategy allows the operating system to temporarily suspend a process that is logically run able, so that the CPU can be freed for a different assignment.

First-Come-First-Served (FCFS) In this algorithm, the ready queue is set up as a standard FIFO queue. Thus the process to be selected next is the process at the front of the ready queue. Though it is extremely simple to implement FIFO strategy, its performance may often be poor compared to other algorithms. FCFS may cause processes with short processor bursts to wait for a long time. If one process with a long processor burst gets the processor, all the others will have to wait for it to finish. As an example, let us consider the following 4 processes along with their arrival times, and the CPU burst times.

Scheduling Algorithms Now, we discuss a few CPU scheduling algorithms.

If we use the FCFS algorithm on the processes, then the processs com- pletion times would be as illustrated in the following timing (Gannt) chart: Processor utilization = (16 / 16) * 100 = 100% 6

Figure 4: Example processes with arrival times and CPU usage times

Shortest-Process-First (SPF) / Shortest Job First. In this method, the CPU is assigned to the process with the smallest execution (processor burst) time. This requires the knowledge of execution time. In our examples, we have simply assumed the CPU burst times. They are not known in a real situation, until the processs actually runs on the CPU. So it is not feasible to implement the algorithm with the exact next CPU burst times. However, one may predict the next CPU burst using the past history of CPU bursts. SPF is provably the best scheduling scheme that minimizes the average waiting time. To illustrate this algorithm, let us consider the same process table of figure 4. The the processs completion times for SPF would be as illustrated below. Processor utilization = (16 / 16) * 100 = 100%

Throughput = 4 / 16 = 0.25 Let tat(p) denote the turnaround time for process p. Note that tat(p) = completion time of (p) - arrival time (p). Therefore, tat(P1 ) = 4, tat(P2 ) = 10, tat(P3 ) = 11, and tat(P4 ) = 10. Average tat = (4+10+11+10) / 4. Let wt(p) denote the waiting time for process p. wt(P1 ) = 0, wt(P2 ) = 2, wt(P3 ) = 9, and wt(P4 ) = 8. Average wt = (0+2+9+8) / 4.

Figure 5: FCFS completion times for the processes

For example consider the same process table as before. The process completion times for SRTF would be exactly as that of SPF (see fig. 6. As another example suppose we have the following 4 processes with arrivals and CPU bursts as indicated in the following table. The processs completion times for SRTF would be as follows.

Shortest-Remaining-Time-First (SRTF) The scheduling algorithms we discussed so far are all non-preemptive algorithms. The SPF can be tailored to be a preemptive one. Assume while one process is executing on the processor, another process arrives. The new process may have a predicted next CPU burst time shorter than what is left of the currently executing process. If the SPF algorithm is preemptive, the currently executing process will be preempted and the new process will start executing. The modified SPF algorithm is named ShortestRemaining-Time-First (SRTF) algorithm.

Throughput = 4 / 16 = 0.25 tat(P1 ) = (4-0)=4, tat(P2 ) = (16-2) =14, tat(P3 ) = (6-3)=3, and tat(P4 ) = (8-6)=2. Average tat = (4+14+3+2) / 4. wt(P1 ) = 0, wt(P2 ) =(8-2)= 6, wt(P3 ) = (4-3)=1, and wt(P4 ) = (6-6)=0. Average wt = (0+6+1+0) / 4.

Figure 6: SPF completion times for the processes

Figure 7: Example processes for SRTF algorithm illustration

Processor utilization = (17 / 17) * 100 = 100% Throughput = 4 / 17. tat(P1 ) = 17, tat(P2 ) = 9, tat(P3 ) = 2, and tat(P4 ) = 2. Average tat = (17+9+2+2) / 4. wt(P1 ) = 9, wt(P2 ) = 4, wt(P3 ) = 0, and wt(P4 ) = 0. Average wt = (9+4+0+0) / 4.

Figure 8: SRTF completion times for the processes

Round-Robin Scheduling (RR) In the RR scheduling scheme the ready queue is treated as a FIFO circular queue. The process that is in the front of the queue gets the CPU. However, the process can use the CPU for no more than a predetermined time period called the time quantum (or time slice). The dispatcher of the process sets a timer to interrupt after one time quantum. During this time slice, one of the following two things could happen. The process requires some other event to happen (such as I/O completion) and therefore releases the CPU and then goes to the wait state. On the other hand, the process could continue to

Priority Scheduling As the name suggests, in this scheme, a priority is associated with each process and the CPU is given to the process with the highest priority. Equal priority processes are scheduled with FCFS method. Indeed, SPF is a special case of priority scheduling algorithm where Priority(i) is the inverse of the next CPU burst time of process i. Priorities can be defined externally or they may be computed by the operating system internally from time to time. A priority scheduling algorithm can leave some low-priority processes starving for the CPU in the ready queue indefinitely. If the system is heavily loaded, it is likely that the CPU is used by some higher-priority process all the time. One solution for the starvation problem is to periodically increment the priority of the processes that are in the ready queue. Priority scheduling can be implemented as a preemptive algorithm as well. In the preemptive priority scheduling scheme, when a higher priority process arrives at the ready queue, the lesser priority process currently running gets preempted and is inserted into the ready queue while the higher priority process is dispatched. This is normally the CPU scheduling strategy used in real time systems. Multilevel ready queues So far we have assumed that all processes that are in the ready state are placed in a single list or queue. However, one can identify and divide the processes into several classes; the processes that belong to a particular class can be placed in their own ready queue. For example consider the following set of ready queues.

compute; in this case, as soon as the timer interrupt occurs the process is preempted and inserted back at the end of the ready queue. Thus, it gets the CPU again only after each process ahead of it in the ready queue has used the CPU once. The performance of RR scheduling depends heavily on the selected time quantum. If there are n processes in the ready queue and the time quantum is q, then each process gets 1/n of the CPU time (ignoring the context switching time) in chunks of at most q time units. Thus in the RR scheduling, assuming a study queue of an average n processes, the response time for each process is no more than (n 1) q. If the time quantum q is too large then the algorithm degenerates to that of FCFS. If it is too small, then the context switch time will be a big overhead. As an illustration, suppose that we have only one process which requires a total of 12 time units to complete. If our RR time quantum q 12, then the process finishes in one time quantum. On the other hand, suppose we set q = 4, then it requires the CPU 3 times. Each of these times, some CPU time is used for the context switching (that is, the time required to save the status of the interrupted process and the time required to dispatch the process). This context switching time is pure overhead. Thus the smaller a time quantum, the more required context switches, and therefore the more overhead.

In multilevel queue scheduling, a process is assigned to a particular queue, based on some property of the process as indicated in figure ??. Each time the process state becomes ready, it enters into the same queue as before. Each queue can use its own scheduling scheme. Moreover, there can be priorities (levels) defined among the queues. For example, one such scenario could be as follows: Each queue has absolute priority over the one

Figure 9: Multiple ready queues with priorities

below it. No process in a lower level queue can run unless all the higher priority queues above it are empty. In our example (figure 9) no process in the student queue can run unless the top three queues are empty. This could lead to starvation of lower priority queue processes. To handle this situation, we can time slice between the queues. In our example, we can allocate 80% of the CPU time to the first three higher level queues and 20% to the student processes.

For example consider the following system of three ready queues. A new process entering into the system is placed in the top ready queue (time slice = 8 millisecs). If a process from this queue consumes less than 8 milliseconds of CPU time, it re-enters this queue when it becomes a ready process again. Any process that attempts to consume more than 8 milliseconds is moved to the middle queue(time slice = 16 millisecs). Processes from this queue re-enter the same queue as long as their CPU burst times are less than 16 milliseconds. All processes that are in violation of this are moved to the third (lower level) queue where

Multilevel feedback queues The multilevel queue sheduling discussed before is rather inflexible because the processes are permanently assigned to specific queues. In contrast, we can allow process migration to other queues based on some predefined criteria. Such queues, where processes are allowed to migrate between queues, is referred to as multilevel feedback queues. In this setting, all new processes first enter into the same (initial) queue. As processes execute, based on their performance (in terms of CPU utilization) they migrate to other queues. Multilevel feedback queue scheduling selects a process in the highest priority queue and runs that process. If the process uses more than a predefined slice of CPU time, it will be moved to a lower priority queue. Similarly, a process that is waiting too long in a lower priority queue could be moved to a higher priority queue to prevent starvation.

the scheduling is done using FCFS algorithm. Moreover, one could assign priorities between the queues where each higher level queue has absolute priority over the queue below it.

Figure 10: Multiple ready queues with priorities