Using Preemption Scheduling Processes and Threads

short job long job short job long job average average start start By repeating this argument, we see that for every two adjacent jobs, we should run the shorter one first in order to reduce the average response time. Switching pairs of jobs like this is akin to bubble-sorting the jobs in order of increasing runtime. The minimal average response time is achieved when the jobs are sorted, and the shortest ones are first. Exercise 54 Is SJF also optimal for other metrics, such as minimizing the average slowdown? But real systems are on-line In real system you typically don’t know much in advance. In particular, new jobs may arrive unexpectedly at arbitrary times. Over the lifetime of a system, the scheduler will be invoked a very large number of times, and each time there will only be a small number of new jobs. Thus it seems ill-advised to emphasize the behavior of the scheduler in a single invocation. Instead, one should consider how it handles all the arrivals that occur over a long stretch of time. On-line algorithms get information about one job at a time, and need to decide immediately what to do with it: either schedule it or put it in a queue to be scheduled later. The decision may of course be influenced by the past e.g. by previously arrived jobs that are already in the queue, but not by the future. The on-line model is also applicable to interactive or IO-bound jobs, which have bursts of CPU activity separated by IO operations for interactive jobs, this is termi- nal IO. Whenever an IO operation completes, the job has to be scheduled again for its next CPU burst. An important tool for handling a changing situation is preemption.

3.3.3 Using Preemption

Preemption is the action of stopping a running job and scheduling another in its place. Switching from one job to another is called a context switch. Technically, this is done by storing the CPU register values of the running process in its PCB, selecting an alternative process that is ready to run, and loading the CPU register values of the selected process. As this includes the PC, the CPU will now continue to run the selected process from where is left off when it was preempted. 69 On-line algorithms use preemption to handle changing conditions On-line algorithms do not know about their input in advance: they get it piecemeal as time advances. Therefore they might make a scheduling decision based on cur- rent data, and then regret it when an additional job arrives. The solution is to use preemption in order to undo the previous decision. We start by reversing the first of the two assumptions made earlier. Thus we now assume that 1. Jobs may arrive unpredictably and the scheduler must deal with those that have already arrived without knowing about future arrivals 2. Nevertheless, when a job arrives its runtime is known in advance. The version of SJF used in this context is called “shortest remaining time first” SRT 2 . As each new job arrives, its runtime is compared with the remaining runtime of the currently running job. If the new job is shorter, the current job is preempted and the new job is run in its place. Otherwise the current job is allowed to continue its execution, and the new job is placed in the appropriate place in the sorted queue. Exercise 55 Is SRT also optimal for other metrics, such as minimizing the average slowdown? A problem with actually using this algorithm is the assumption that the run times of jobs are known. This may be allowed in the theoretical setting of off-line algo- rithms, but is usually not the case in real systems. An interesting counter example is provided by web servers that only serve static pages. In this case, the service time of a page is essentially proportional to the page size. Thus when a request for a certain page arrives, we can get a pretty accurate as- sessment of how long it will take to serve, based on the requested page’s size. Schedul- ing web servers in this way turns out to improve performance significantly for small pages, without too much effect on large ones [6]. Preemption can also compensate for lack of knowledge SRT only preempts the current job when a shorter one arrives, which relies on the assumption that runtimes are known in advance. But a more realistic set of assump- tions is that 1. Jobs may arrive unpredictably, and 2. Job runtimes are not known in advance. 2 Sometimes also called “shortest remaining processing time first”, or SRPT. 70 Using more preemptions can compensate for this lack of knowledge. The idea is to schedule each job for a short time quantum, and then preempt it and schedule another job in its place. The jobs are scheduled in round robin order: a cycle is formed, and each gets one time quantum. Thus the delay until a new job gets to run is limited to one cycle, which is the product of the number of jobs times the length of the time quantum. If a job is short, it will terminate within its first quantum, and have a relatively short response time. If it is long, it will have to wait for additional quanta. The system does not have to know in advance which jobs are short and which are long. Exercise 56 Round robin scheduling is often implemented by keeping a circular linked list of the PCBs, and a pointer to the current one. Is it better to insert new jobs just before the current pointer or just after it? Note that when each process just runs for a short time, we are actually time slic- ing the CPU. This results in a viable approximation to processor sharing, which was shown on page 60 to prevent situations in which a short job gets stuck behind a long one. In fact, the time it takes to run each job is more-or-less proportional to its own length, multiplied by the current load. This is beneficial due to the high variability of process runtimes: most are very short, but some are very long. 2 job 1 2 1 2 3 1 2 3 1 2 1 job 1 arrives job2 arrives job3 arrives time job 1 job2 job3 terminates terminates terminates Exercise 57 Should the time slices be long or short? Why? Using preemption regularly ensures that the system stays in control But how are time quanta enforced? This is another example where the operating sys- tem needs some help from the hardware. The trick is to have a hardware clock that causes periodic interrupts e.g. 100 times a second, or every 10 ms. This interrupt, like all other interrupts, is handled by a special operating system function. Specif- ically, this handler may make scheduling decisions and may decide to preempt the currently running process. An important benefit of having such periodic clock interrupts is that they ensure that the system regains control over the CPU. Without them, a rogue process may never relinquish the CPU, and prevent all other processes from using the system. In reality, however, the question of scheduling quanta is almost mute. In the vast majority of cases, the effective quantum is much shorter than the allocated quantum. 71 This is so because in most cases the process performs a system call or an external interrupt happens [4]. The clock interrupt therefore serves mainly as a backup. And it also improves fairness Finally, we note that even if processes do not engage in infinite loops, some are compute-bound while others are interactive or IO-bound. Without preemption, CPU-bound processes may lock out the interactive processes for excessive periods, which is undesirable. Preempting them regularly allows interactive processes to get a chance to run, at least once in a while. But if there are many compute-bound pro- cesses, this may not be enough. The solution is then to give the interactive processes higher priorities.

3.3.4 Priority Scheduling