2 S CHEDULING : I NTRODUCTION

a fully-operational scheduling discipline1 .

We will make the following assumptions about the processes, some-
times called jobs, that are running in the system:
1. Each job runs for the same amount of time.
2. All jobs arrive at the same time.
3. Once started, each job runs to completion.
4. All jobs only use the CPU (i.e., they perform no I/O)
5. The run-time of each job is known.
We said many of these assumptions were unrealistic, but just as some
animals are more equal than others in Orwell’s Animal Farm [O45], some
assumptions are more unrealistic than others in this chapter. In particu-
lar, it might bother you that the run-time of each job is known: this would
make the scheduler omniscient, which, although it would be great (prob-
ably), is not likely to happen anytime soon.

7.2 Scheduling Metrics

Beyond making workload assumptions, we also need one more thing
to enable us to compare different scheduling policies: a scheduling met-
ric. A metric is just something that we use to measure something, and
there are a number of different metrics that make sense in scheduling.
For now, however, let us also simplify our life by simply having a sin-
gle metric: turnaround time. The turnaround time of a job is defined
as the time at which the job completes minus the time at which the job
arrived in the system. More formally, the turnaround time Tturnaround is:

Tturnaround = Tcompletion − Tarrival (7.1)

Because we have assumed that all jobs arrive at the same time, for now
Tarrival = 0 and hence Tturnaround = Tcompletion . This fact will change
as we relax the aforementioned assumptions.
You should note that turnaround time is a performance metric, which
will be our primary focus this chapter. Another metric of interest is fair-
ness, as measured (for example) by Jain’s Fairness Index [J91]. Perfor-
mance and fairness are often at odds in scheduling; a scheduler, for ex-
ample, may optimize performance but at the cost of preventing a few jobs
from running, thus decreasing fairness. This conundrum shows us that
life isn’t always perfect.

7.3 First In, First Out (FIFO)

The most basic algorithm we can implement is known as First In, First
Out (FIFO) scheduling or sometimes First Come, First Served (FCFS).
1
Said in the same way you would say “A fully-operational Death Star.”

O PERATING
S YSTEMS WWW. OSTEP. ORG
[V ERSION 1.10]
 2 S CHEDULING : I NTRODUCTION

a fully-operational scheduling discipline1 .

We will make the following assumptions about the processes, some-
times called jobs, that are running in the system:
1. Each job runs for the same amount of time.
2. All jobs arrive at the same time.
3. Once started, each job runs to completion.
4. All jobs only use the CPU (i.e., they perform no I/O)
5. The run-time of each job is known.
We said many of these assumptions were unrealistic, but just as some
animals are more equal than others in Orwell’s Animal Farm [O45], some
assumptions are more unrealistic than others in this chapter. In particu-
lar, it might bother you that the run-time of each job is known: this would
make the scheduler omniscient, which, although it would be great (prob-
ably), is not likely to happen anytime soon.

7.2 Scheduling Metrics

Beyond making workload assumptions, we also need one more thing
to enable us to compare different scheduling policies: a scheduling met-
ric. A metric is just something that we use to measure something, and
there are a number of different metrics that make sense in scheduling.
For now, however, let us also simplify our life by simply having a sin-
gle metric: turnaround time. The turnaround time of a job is defined
as the time at which the job completes minus the time at which the job
arrived in the system. More formally, the turnaround time Tturnaround is:

Tturnaround = Tcompletion − Tarrival (7.1)

Because we have assumed that all jobs arrive at the same time, for now
Tarrival = 0 and hence Tturnaround = Tcompletion . This fact will change
as we relax the aforementioned assumptions.
You should note that turnaround time is a performance metric, which
will be our primary focus this chapter. Another metric of interest is fair-
ness, as measured (for example) by Jain’s Fairness Index [J91]. Perfor-
mance and fairness are often at odds in scheduling; a scheduler, for ex-
ample, may optimize performance but at the cost of preventing a few jobs
from running, thus decreasing fairness. This conundrum shows us that
life isn’t always perfect.

7.3 First In, First Out (FIFO)

The most basic algorithm we can implement is known as First In, First
Out (FIFO) scheduling or sometimes First Come, First Served (FCFS).
1
Said in the same way you would say “A fully-operational Death Star.”

O PERATING
S YSTEMS WWW. OSTEP. ORG
[V ERSION 1.10]
 2 S CHEDULING : I NTRODUCTION

a fully-operational scheduling discipline1 .

We will make the following assumptions about the processes, some-
times called jobs, that are running in the system:
1. Each job runs for the same amount of time.
2. All jobs arrive at the same time.
3. Once started, each job runs to completion.
4. All jobs only use the CPU (i.e., they perform no I/O)
5. The run-time of each job is known.
We said many of these assumptions were unrealistic, but just as some
animals are more equal than others in Orwell’s Animal Farm [O45], some
assumptions are more unrealistic than others in this chapter. In particu-
lar, it might bother you that the run-time of each job is known: this would
make the scheduler omniscient, which, although it would be great (prob-
ably), is not likely to happen anytime soon.

7.2 Scheduling Metrics

Beyond making workload assumptions, we also need one more thing
to enable us to compare different scheduling policies: a scheduling met-
ric. A metric is just something that we use to measure something, and
there are a number of different metrics that make sense in scheduling.
For now, however, let us also simplify our life by simply having a sin-
gle metric: turnaround time. The turnaround time of a job is defined
as the time at which the job completes minus the time at which the job
arrived in the system. More formally, the turnaround time Tturnaround is:

Tturnaround = Tcompletion − Tarrival (7.1)

Because we have assumed that all jobs arrive at the same time, for now
Tarrival = 0 and hence Tturnaround = Tcompletion . This fact will change
as we relax the aforementioned assumptions.
You should note that turnaround time is a performance metric, which
will be our primary focus this chapter. Another metric of interest is fair-
ness, as measured (for example) by Jain’s Fairness Index [J91]. Perfor-
mance and fairness are often at odds in scheduling; a scheduler, for ex-
ample, may optimize performance but at the cost of preventing a few jobs
from running, thus decreasing fairness. This conundrum shows us that
life isn’t always perfect.

7.3 First In, First Out (FIFO)

The most basic algorithm we can implement is known as First In, First
Out (FIFO) scheduling or sometimes First Come, First Served (FCFS).
1
Said in the same way you would say “A fully-operational Death Star.”

O PERATING
S YSTEMS WWW. OSTEP. ORG
[V ERSION 1.10]
 S CHEDULING : I NTRODUCTION 5

A SIDE : P REEMPTIVE S CHEDULERS

In the old days of batch computing, a number of non-preemptive sched-
ulers were developed; such systems would run each job to completion
before considering whether to run a new job. Virtually all modern sched-
ulers are preemptive, and quite willing to stop one process from run-
ning in order to run another. This implies that the scheduler employs the
mechanisms we learned about previously; in particular, the scheduler can
perform a context switch, stopping one running process temporarily and
resuming (or starting) another.

In fact, given our assumptions about jobs all arriving at the same time,
we could prove that SJF is indeed an optimal scheduling algorithm. How-
ever, you are in a systems class, not theory or operations research; no
proofs are allowed.
Thus we arrive upon a good approach to scheduling with SJF, but our
assumptions are still fairly unrealistic. Let’s relax another. In particular,
we can target assumption 2, and now assume that jobs can arrive at any
time instead of all at once. What problems does this lead to?
(Another pause to think ... are you thinking? Come on, you can do it)
Here we can illustrate the problem again with an example. This time,
assume A arrives at t = 0 and needs to run for 100 seconds, whereas B
and C arrive at t = 10 and each need to run for 10 seconds. With pure
SJF, we’d get the schedule seen in Figure 7.4.
[B,C arrive]
A B C

0 20 40 60 80 100 120
Time
Figure 7.4: SJF With Late Arrivals From B and C
As you can see from the figure, even though B and C arrived shortly
after A, they still are forced to wait until A has completed, and thus suffer
the same convoy problem. Average turnaround time for these three jobs
is 103.33 seconds ( 100+(110−10)+(120−10)
3
). What can a scheduler do?

7.5 Shortest Time-to-Completion First (STCF)

To address this concern, we need to relax assumption 3 (that jobs must
run to completion), so let’s do that. We also need some machinery within
the scheduler itself. As you might have guessed, given our previous dis-
cussion about timer interrupts and context switching, the scheduler can

T HREE
© 2008–23, A RPACI -D USSEAU
E ASY
P IECES
 S CHEDULING : I NTRODUCTION 5

A SIDE : P REEMPTIVE S CHEDULERS

In the old days of batch computing, a number of non-preemptive sched-
ulers were developed; such systems would run each job to completion
before considering whether to run a new job. Virtually all modern sched-
ulers are preemptive, and quite willing to stop one process from run-
ning in order to run another. This implies that the scheduler employs the
mechanisms we learned about previously; in particular, the scheduler can
perform a context switch, stopping one running process temporarily and
resuming (or starting) another.

In fact, given our assumptions about jobs all arriving at the same time,
we could prove that SJF is indeed an optimal scheduling algorithm. How-
ever, you are in a systems class, not theory or operations research; no
proofs are allowed.
Thus we arrive upon a good approach to scheduling with SJF, but our
assumptions are still fairly unrealistic. Let’s relax another. In particular,
we can target assumption 2, and now assume that jobs can arrive at any
time instead of all at once. What problems does this lead to?
(Another pause to think ... are you thinking? Come on, you can do it)
Here we can illustrate the problem again with an example. This time,
assume A arrives at t = 0 and needs to run for 100 seconds, whereas B
and C arrive at t = 10 and each need to run for 10 seconds. With pure
SJF, we’d get the schedule seen in Figure 7.4.
[B,C arrive]
A B C

0 20 40 60 80 100 120
Time
Figure 7.4: SJF With Late Arrivals From B and C
As you can see from the figure, even though B and C arrived shortly
after A, they still are forced to wait until A has completed, and thus suffer
the same convoy problem. Average turnaround time for these three jobs
is 103.33 seconds ( 100+(110−10)+(120−10)
3
). What can a scheduler do?

7.5 Shortest Time-to-Completion First (STCF)

To address this concern, we need to relax assumption 3 (that jobs must
run to completion), so let’s do that. We also need some machinery within
the scheduler itself. As you might have guessed, given our previous dis-
cussion about timer interrupts and context switching, the scheduler can

T HREE
© 2008–23, A RPACI -D USSEAU
E ASY
P IECES
 S CHEDULING : I NTRODUCTION 5

A SIDE : P REEMPTIVE S CHEDULERS

In the old days of batch computing, a number of non-preemptive sched-
ulers were developed; such systems would run each job to completion
before considering whether to run a new job. Virtually all modern sched-
ulers are preemptive, and quite willing to stop one process from run-
ning in order to run another. This implies that the scheduler employs the
mechanisms we learned about previously; in particular, the scheduler can
perform a context switch, stopping one running process temporarily and
resuming (or starting) another.

In fact, given our assumptions about jobs all arriving at the same time,
we could prove that SJF is indeed an optimal scheduling algorithm. How-
ever, you are in a systems class, not theory or operations research; no
proofs are allowed.
Thus we arrive upon a good approach to scheduling with SJF, but our
assumptions are still fairly unrealistic. Let’s relax another. In particular,
we can target assumption 2, and now assume that jobs can arrive at any
time instead of all at once. What problems does this lead to?
(Another pause to think ... are you thinking? Come on, you can do it)
Here we can illustrate the problem again with an example. This time,
assume A arrives at t = 0 and needs to run for 100 seconds, whereas B
and C arrive at t = 10 and each need to run for 10 seconds. With pure
SJF, we’d get the schedule seen in Figure 7.4.
[B,C arrive]
A B C

0 20 40 60 80 100 120
Time
Figure 7.4: SJF With Late Arrivals From B and C
As you can see from the figure, even though B and C arrived shortly
after A, they still are forced to wait until A has completed, and thus suffer
the same convoy problem. Average turnaround time for these three jobs
is 103.33 seconds ( 100+(110−10)+(120−10)
3
). What can a scheduler do?

7.5 Shortest Time-to-Completion First (STCF)

To address this concern, we need to relax assumption 3 (that jobs must
run to completion), so let’s do that. We also need some machinery within
the scheduler itself. As you might have guessed, given our previous dis-
cussion about timer interrupts and context switching, the scheduler can

T HREE
© 2008–23, A RPACI -D USSEAU
E ASY
P IECES
8 S CHEDULING : I NTRODUCTION

T IP : A MORTIZATION C AN R EDUCE C OSTS

The general technique of amortization is commonly used in systems
when there is a fixed cost to some operation. By incurring that cost less
often (i.e., by performing the operation fewer times), the total cost to the
system is reduced. For example, if the time slice is set to 10 ms, and the
context-switch cost is 1 ms, roughly 10% of time is spent context switch-
ing and is thus wasted. If we want to amortize this cost, we can increase
the time slice, e.g., to 100 ms. In this case, less than 1% of time is spent
context switching, and thus the cost of time-slicing has been amortized.

they each wish to run for 5 seconds. An SJF scheduler runs each job to
completion before running another (Figure 7.6). In contrast, RR with a
time-slice of 1 second would cycle through the jobs quickly (Figure 7.7).
The average response time of RR is: 0+1+2 3
= 1; for SJF, average re-
sponse time is: 0+5+10
3
= 5.
As you can see, the length of the time slice is critical for RR. The shorter
it is, the better the performance of RR under the response-time metric.
However, making the time slice too short is problematic: suddenly the
cost of context switching will dominate overall performance. Thus, de-
ciding on the length of the time slice presents a trade-off to a system de-
signer, making it long enough to amortize the cost of switching without
making it so long that the system is no longer responsive.
Note that the cost of context switching does not arise solely from the
OS actions of saving and restoring a few registers. When programs run,
they build up a great deal of state in CPU caches, TLBs, branch predictors,
and other on-chip hardware. Switching to another job causes this state
to be flushed and new state relevant to the currently-running job to be
brought in, which may exact a noticeable performance cost [MB91].
RR, with a reasonable time slice, is thus an excellent scheduler if re-
sponse time is our only metric. But what about our old friend turnaround
time? Let’s look at our example above again. A, B, and C, each with run-
ning times of 5 seconds, arrive at the same time, and RR is the scheduler
with a (long) 1-second time slice. We can see from the picture above that
A finishes at 13, B at 14, and C at 15, for an average of 14. Pretty awful!
It is not surprising, then, that RR is indeed one of the worst policies if
turnaround time is our metric. Intuitively, this should make sense: what
RR is doing is stretching out each job as long as it can, by only running
each job for a short bit before moving to the next. Because turnaround
time only cares about when jobs finish, RR is nearly pessimal, even worse
than simple FIFO in many cases.
More generally, any policy (such as RR) that is fair, i.e., that evenly di-
vides the CPU among active processes on a small time scale, will perform
poorly on metrics such as turnaround time. Indeed, this is an inherent
trade-off: if you are willing to be unfair, you can run shorter jobs to com-
pletion, but at the cost of response time; if you instead value fairness,

O PERATING
S YSTEMS WWW. OSTEP. ORG
[V ERSION 1.10]
8 S CHEDULING : I NTRODUCTION

T IP : A MORTIZATION C AN R EDUCE C OSTS

The general technique of amortization is commonly used in systems
when there is a fixed cost to some operation. By incurring that cost less
often (i.e., by performing the operation fewer times), the total cost to the
system is reduced. For example, if the time slice is set to 10 ms, and the
context-switch cost is 1 ms, roughly 10% of time is spent context switch-
ing and is thus wasted. If we want to amortize this cost, we can increase
the time slice, e.g., to 100 ms. In this case, less than 1% of time is spent
context switching, and thus the cost of time-slicing has been amortized.

they each wish to run for 5 seconds. An SJF scheduler runs each job to
completion before running another (Figure 7.6). In contrast, RR with a
time-slice of 1 second would cycle through the jobs quickly (Figure 7.7).
The average response time of RR is: 0+1+2 3
= 1; for SJF, average re-
sponse time is: 0+5+10
3
= 5.
As you can see, the length of the time slice is critical for RR. The shorter
it is, the better the performance of RR under the response-time metric.
However, making the time slice too short is problematic: suddenly the
cost of context switching will dominate overall performance. Thus, de-
ciding on the length of the time slice presents a trade-off to a system de-
signer, making it long enough to amortize the cost of switching without
making it so long that the system is no longer responsive.
Note that the cost of context switching does not arise solely from the
OS actions of saving and restoring a few registers. When programs run,
they build up a great deal of state in CPU caches, TLBs, branch predictors,
and other on-chip hardware. Switching to another job causes this state
to be flushed and new state relevant to the currently-running job to be
brought in, which may exact a noticeable performance cost [MB91].
RR, with a reasonable time slice, is thus an excellent scheduler if re-
sponse time is our only metric. But what about our old friend turnaround
time? Let’s look at our example above again. A, B, and C, each with run-
ning times of 5 seconds, arrive at the same time, and RR is the scheduler
with a (long) 1-second time slice. We can see from the picture above that
A finishes at 13, B at 14, and C at 15, for an average of 14. Pretty awful!
It is not surprising, then, that RR is indeed one of the worst policies if
turnaround time is our metric. Intuitively, this should make sense: what
RR is doing is stretching out each job as long as it can, by only running
each job for a short bit before moving to the next. Because turnaround
time only cares about when jobs finish, RR is nearly pessimal, even worse
than simple FIFO in many cases.
More generally, any policy (such as RR) that is fair, i.e., that evenly di-
vides the CPU among active processes on a small time scale, will perform
poorly on metrics such as turnaround time. Indeed, this is an inherent
trade-off: if you are willing to be unfair, you can run shorter jobs to com-
pletion, but at the cost of response time; if you instead value fairness,

O PERATING
S YSTEMS WWW. OSTEP. ORG
[V ERSION 1.10]
8 S CHEDULING : I NTRODUCTION

T IP : A MORTIZATION C AN R EDUCE C OSTS

The general technique of amortization is commonly used in systems
when there is a fixed cost to some operation. By incurring that cost less
often (i.e., by performing the operation fewer times), the total cost to the
system is reduced. For example, if the time slice is set to 10 ms, and the
context-switch cost is 1 ms, roughly 10% of time is spent context switch-
ing and is thus wasted. If we want to amortize this cost, we can increase
the time slice, e.g., to 100 ms. In this case, less than 1% of time is spent
context switching, and thus the cost of time-slicing has been amortized.

they each wish to run for 5 seconds. An SJF scheduler runs each job to
completion before running another (Figure 7.6). In contrast, RR with a
time-slice of 1 second would cycle through the jobs quickly (Figure 7.7).
The average response time of RR is: 0+1+2 3
= 1; for SJF, average re-
sponse time is: 0+5+10
3
= 5.
As you can see, the length of the time slice is critical for RR. The shorter
it is, the better the performance of RR under the response-time metric.
However, making the time slice too short is problematic: suddenly the
cost of context switching will dominate overall performance. Thus, de-
ciding on the length of the time slice presents a trade-off to a system de-
signer, making it long enough to amortize the cost of switching without
making it so long that the system is no longer responsive.
Note that the cost of context switching does not arise solely from the
OS actions of saving and restoring a few registers. When programs run,
they build up a great deal of state in CPU caches, TLBs, branch predictors,
and other on-chip hardware. Switching to another job causes this state
to be flushed and new state relevant to the currently-running job to be
brought in, which may exact a noticeable performance cost [MB91].
RR, with a reasonable time slice, is thus an excellent scheduler if re-
sponse time is our only metric. But what about our old friend turnaround
time? Let’s look at our example above again. A, B, and C, each with run-
ning times of 5 seconds, arrive at the same time, and RR is the scheduler
with a (long) 1-second time slice. We can see from the picture above that
A finishes at 13, B at 14, and C at 15, for an average of 14. Pretty awful!
It is not surprising, then, that RR is indeed one of the worst policies if
turnaround time is our metric. Intuitively, this should make sense: what
RR is doing is stretching out each job as long as it can, by only running
each job for a short bit before moving to the next. Because turnaround
time only cares about when jobs finish, RR is nearly pessimal, even worse
than simple FIFO in many cases.
More generally, any policy (such as RR) that is fair, i.e., that evenly di-
vides the CPU among active processes on a small time scale, will perform
poorly on metrics such as turnaround time. Indeed, this is an inherent
trade-off: if you are willing to be unfair, you can run shorter jobs to com-
pletion, but at the cost of response time; if you instead value fairness,

O PERATING
S YSTEMS WWW. OSTEP. ORG
[V ERSION 1.10]