The chosen metric should be one that reflects the scheduler’s performance
Not all metrics are equally applicable. For example, in many real-world situations, users submit jobs according to their needs. The ratio of the requirements of all the
jobs to the available resources of the system then determines the utilization, and does not directly reflect the scheduler’s performance. There is only an indirect effect:
a bad scheduler will discourage users from submitting more jobs, so the utilization will drop.
In a nutshell, utilization and throughput are more directly linked to the workload imposed by users than to the scheduler. They become important when the system is
overloaded. Metrics related to response time are generally better for the evaluation of schedulers, especially in an interactive setting.
3.3.2 Handling a Given Set of Jobs
While the operating system in general is reactive, the scheduling algorithm itself is not. A scheduling algorithm has inputs, performs a computation, and terminates pro-
ducing an output. The input is information about the jobs that need to be scheduled. the output is the schedule: a decision when to run each job, or at least a decision
which job to run now.
We start by considering off-line algorithms, that only handle a given set of jobs that are all available at the outset.
Off-line means everything is known in advance
One important distinction is between on-line and off-line algorithms. Off-line algo- rithms receive complete information in advance. Thus they are subject to two as-
sumptions:
1. All jobs are available at the outset and none arrive later. 2. The job runtimes are also known in advance.
The assumption that all jobs are known in advance has two variants. The first is that all these jobs are currently available, and this is the set of jobs that the schedul-
ing algorithm needs to handle. This is a reasonable assumption in the context of an algorithm that is invoked repeatedly by the operating system whenever it is needed
e.g. when the situation changes because additional jobs arrive.
The second variant assumes knowledge about jobs that will arrive in the future e.g. “another job will arrive in 13 minutes”. This essentially assumes that everything
is known in advance, and the algorithm is only called once. Such a scenario is mainly of theoretical interest, as it may provide us with a bound of what can be achieved with
full knowledge. However, it is typically not directly relevant to the implementation of real systems.
67
The assumption that runtimes are known in advance is also problematic. While there are some situations in which runtimes are known in advance, in most cases this
is not the case.
Off-line algorithms run jobs to completion
Given that off-line algorithms get all their required information at the outset, and that all relevant jobs are available for scheduling, they can expect no surprises during
execution. In fact, they complete the schedule before execution even begins.
Under these circumstances, there is no reason to ever preempt a job. Response time and throughput metrics depend on job completion times, so once a job is started
it is best to complete it as soon as possible; if running another job would improve the metric, that other job should have been scheduled in the first place. Utilization is
maximized as long as any job is running, so it is not a very relevant metric for off-line algorithms.
The result is that off-line algorithms use “run to completion” RTC: each job is executed until it terminates, and the algorithm is only concerned with the order in
which jobs are started.
Exercise 53 The above argument is correct when we are only scheduling on one re- source, e.g. the CPU. Does this change if there are multiple CPUs, but each job only
needs one of them? What about jobs that may need more than one CPU that is, paral- lel jobs?
FCFS is the base case
The base case for RTC scheduling algorithms is First-Come First-Serve FCFS. This algorithm simply schedules the jobs in the order in which they arrive, and runs each
one to completion. For the off-line case, the jobs are run in the order that they appear in the input.
Running short jobs first improves the average response time
Reordering the jobs so as to run the shortest jobs first SJF improves the average response time. Consider two adjacent jobs, one longer than the other. Because the
total time for both jobs is constant, the second job will terminate at the same time regardless of their order. But if the shorter one is executed first, its termination time
will be shorter than if the long one is executed first. As a result, the average is also reduced when the shorter job is executed first:
68
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
