You are on page 1of 12

J.E.D.I.

1 Process Scheduling
1.1

Objectives

This chapter introduces the different ways processes in the ready queue. We will focus on the
different scheduling schemes available, as well as discuss the scheduling algorithm actually
being used by the Solaris system.

1.2

Chapter Outline

This chapter is divided into the following sections:

Scheduling introduction

First-come-first-serve scheduling

Shortest Job first scheduling

Priority scheduling

Round-robin scheduling

Multi-queue scheduling

Solaris process scheduling

1.3

Introduction

As operating systems allow for multiple processes sharing a single processor, the operating
system must establish a consistent scheme that chooses the next process to run on the CPU in
the event that the currently running process voluntarily or involuntarily relinquishes control of
the CPU.
An analogy for this concept (and we will be using this throughout this chapter) is the idea of
the CPU being a swing in a playground, with processes as children all lining up to use the
swing, which only one child at a time can use. All the children must take turns using the swing
in a way that effectively minimizes swing idle time and would allow all the children to ride on
the swing.
We will now introduce some scheduling concepts.

1.3.1

CPU burst I/O burst cycle

As was discussed in an earlier chapter, a process undergoes a CPU burst I/O burst cycle. A
CPU burst is when the process is running instructions. An I/O burst is when the process is
waiting for some I/O to finish. When the process is waiting for I/O, it sits idle on the CPU,
waiting for the I/O instruction to finish. To allow for more efficient use of the CPU, the process
is removed from the CPU, entering the waiting state. This allows the other process to run their
CPU burst. When the process is finished with its I/O burst, it comes back to the ready queue in
order to have a turn at the CPU to run its next CPU burst.

Operating Systems

J.E.D.I.

CPU I/O Burst cycle


Again, with our playground analogy, eventually a child on the swing will tire and would have to
rest for a while. To make sure that the swing is always used, a different child takes the place in
the swing. After a while, the child would be finished with his rest and would go back to the line
on the swing.

1.3.2

CPU bound, I/O bound processes

A CPU bound process is a process that spends most of its execution in a CPU burst. This would
occur for those process that are primarily computational in nature rather than interactive. An
application that computes the result of complicated mathematical functions is CPU bound.
Photo editing applications as well as applications that render computer graphics are also CPU
bound.
I/O bound processes on the other hand are processes that mostly wait for user input or take
Operating Systems

J.E.D.I.

time to produce user output. Most interactive applications such as word processors and
spreadsheets are usually I/O bound.
This distinction is used by the long-term scheduler to optimize CPU performance. We will
discuss the long-term scheduler later on.

1.3.3

Schedulers

Primarily, when we talk about process scheduling, we consider what is called the short-term
scheduler. The purpose of the short-term scheduler is to choose which process is to run next
on the CPU.
There are four possible times when the process selection is made.

First, a process's CPU burst period ends and begins to wait for I/O. As discussed earlier,
this process is removed from the CPU to allow the CPU burst of other processes to run.

A second scenario is when a process starts. Often, processes are created by other
processes. When you double click an application icon, the mouse control process
spawns the application process. When invoking an application from the command line,
the command line process starts your application process. A decision must be made on
which process to run, the parent process or the child process.

Decisions are also made when a process ends.

A fourth scenario occurs in certain types of scheduling algorithms where the OS itself
revokes a process' turn on the CPU in what is termed as preemption. We will discuss
this in detail in a later section.

For all of these scenarios, the scheduler always tries to maximize CPU use as well as give all
the processes a chance to run. The focus of the rest of this chapter is on what scheduling
algorithms are used by the short term scheduler.
It is worth mentioning that some operating systems come with a long-term scheduler. The
long-term scheduler is responsible for fine-tuning the mix of processes in the ready queue. As
was discussed earlier, processes are either CPU bound or I/O bound. If the processes in the
ready queue are mostly CPU bound, then most of the time a lot of the processes would be
waiting for their turn on the CPU. If most of the processes are I/O bound on the other hand,
then the CPU would be mostly idle as most of the processes would be waiting for I/O to finish
instead of running on the CPU. The long-term scheduler tries to prevent these extremes from
happening. Sometimes, the long-term scheduler may temporarily swap out certain processes
from memory (effectively making these processes halt) in order to maintain an optimal mix of
CPU and I/O bound processes.

1.3.4

Preemption

Some scheduling routines may suddenly forcibly evict a currently running process from the
CPU, even if that process is still not finished with its CPU burst. If this happens, we say that
the scheduling algorithm has a preempted the process.
Preemption may occur when a process with a higher priority enters the ready queue. This will
be discussed in greater detail later on.

1.3.5

Context switch time

The context switch time is the time spent when a process is removed from the CPU in order for
another process to take its place. During the context switch time, the OS writes the Process
Control Block information of the exiting process. After this is done, the OS loads from the
incoming process' Process Control Block the values of the CPU registers, sets memory
Operating Systems

J.E.D.I.

locations, goes to the latest executing instruction of the incoming process in order to pick up
where the process left off.
While this is being done, the CPU is left totally idle. In essence , the CPU does not do any work
while processes are being switched. This is why doing too much process switching actually
decreases CPU utilization, and has a derogatory effect in some scheduling algorithms.

1.3.6

Scheduling criteria

As this chapter discusses different scheduling algorithms, we will introduce some metrics that
would characterize a scheduling algorithm's performance.

CPU utilization a good scheduling algorithm tries to maximize the amount of time the
CPU is doing work.

Turn-around time this describes how long it takes for a process to finish running. This
may not be just dependent on how long the process takes to run. At some point the
process may be waiting for I/O or idle as it waits in line in the ready queue for its turn
to run on the CPU.

Throughput this describes how many processes get finished in a given time. We would
like to have as many processes finished as possible. However, if the scheduler only
chooses processes that take only a short time to run, we would be maximizing
throughput at the expense of turn-around time.

Waiting-time this is how long the process is kept idle in the ready queue

Response time this describes how long does it takes after a user has provided input
before the process can respond. This is more of a subjective measure. Most users are
comfortable with long program loading times but would like a very responsive program
once it is loaded. Typing on the keyboard should have a nearly instantaneous response
(the character should appear on the screen immediately) while copying a file is
expected to take some time.

Fairness the OS must give a chance for all the processes to run on the CPU. Certain
scheduling algorithms have the tendency of picking processes over others, and some
process may end up not running at all. This behavior is called starvation.

1.3.7

Representing process execution

There are many ways to represent process execution. One of the common ways to show which
processes are running on the CPU is via a Gantt chart. For example, the following Gantt chart
shows Process P1 starting at time 0 and ending just before time 15. Process 2 runs for 10
seconds, ending at just before time 25 and so on.

Another way is through a process execution table. Here is an example process execution table:
Scheduling: First-come first-served with context switch time of 1 second.

Operating Systems

J.E.D.I.

Processes: P1 with CPU burst 4, P2 with CPU burst 5, P3 with CPU burst 2 arriving at time 0
P4 with CPU burst 1 arriving at time 2.
Time

CPU

Ready Queue

Comment

P1 (4)

P2 (5), P3 (2)

P1, P2, P3 arrives. P1 chosen to run

P1 (3)

P2 (5), P3 (2)

P1 (2)

P2 (5), P3 (2), P4 (1)

P1 (1)

P2 (5), P3 (2), P4 (1)

idle

P2 (5), P3 (2), P4 (1)

Process 1 ends, context switch time

P2 (5)

P3 (2), P4 (1)

Process 2 chosen to run next

P4 arrives.

Each row of the process execution table shows what the current state of the CPU and the ready
queue is at each second (indicated by the Time column). The CPU column indicates what
process is currently running on the CPU while the ready queue shows the processes in line,
sorted in an order described by the scheduling algorithm. The number in parenthesis next to
the processes indicates burst time left.
The process execution table is a great way to gather our metrics. It should follow that the
process running on the CPU has its burst time left reduced at every time cycle. A process with
4 seconds of burst time should appear for 4 rows on the CPU. The waiting time of a process is
the amount of time it spends in the ready queue. For example, the waiting time of P2 is 5
seconds as it appears for 5 rows in the process execution table. The waiting time for P1 is 0 as
it is immediately chosen to run on the CPU.
To make things simple, most of discussion would not consider a context switch time, although
context switch time plays a pivotal role in some scheduling algorithms and will be mentioned
as such.

1.3.8

Determining CPU burst

In reality, the OS doesn't really know how long the CPU burst of a process is (it would have to
involve program analysis, something the OS is too busy for).
So, our figures for CPU burst are actually determined by analyzing that process' previous CPU
bursts. If we consider tn to be the last CPU burst, and t'n to be our last CPU burst guess, then
we can get our estimate t'n+1 using the formula

t ' n1=a t n 1a t ' n


a in this case is a value between 0 and 1. If a = 0, then it means that our next estimate would
be based on our previous estimate. If a = 1 then we will assume that the next CPU burst is
exactly the same as the previous CPU burst, ignoring all the previous CPU bursts. Often, a is
set to so that both have equal weights.
This formula is called the exponential average because if we expand t' n into the formula
considering t'n-1 and so on, we will end up with the formula:
2

n1

t ' n1 =a t n1a t n1a a t n1 1a a t n21a


1.4

t '0

Scheduling algorithms

We will now discuss the different scheduling algorithms. Operating systems may actually use a
combination of these algorithms and may have more than one queue for ready processes, as
Operating Systems

J.E.D.I.

we will discuss in a later section.


For our examples, we will consider CPU burst times in the scale of a few seconds. In reality,
these burst times are in the millisecond range. We will use seconds in order to easily visualize
the examples.

1.4.1

First-come first-served

Perhaps the simplest scheduling algorithm, the first-come first-served algorithm simply queues
the processes in the order that they arrive. When the process on the CPU is finished with its
CPU burst, the next process in line will be chosen. A newly arriving process is just simply
added to the end of the queue.
For example, we have 4 processes P1 to P4 with burst times 5, 3, 4, 6 arriving in that order at
time 0. Then the Gantt chart of which process is running is as follows.

However, a problem comes with the FCFS algorithm. Consider a process P1 with CPU burst
time of 100 seconds, while 4 process P2 to P5 with burst time of 1 second each. If process
execution is done in the order P1, P2, P3, P4, P5, then the Gantt chart would look like this:

The average waiting time would be: (0 + 100 + 101 + 102 + 103) / 5 = 81.2 seconds
If however, we made P1 run last, then the Gantt chart would look like this:

The average waiting time would then be: (0 + 1 + 2 + 3 + 4) / 5 = 2 seconds. Thus, having
shorter running processes run first greatly decreases waiting time.
To make things work, if P1 enters the queue again, then the entire process execution would
run at the speed of P1 (i.e. Every other process has to wait 100 seconds before running). This
is called as the convoy effect, execution runs at the speed of the slowest process. Some
scheduling algorithms would preempt P1 after a certain amount of time, giving chance for
other processes to run, improving performance.

Operating Systems

J.E.D.I.

Following our analogy, the first-come-first-serve scheme would be the basic strategy for
children wanting to play the swing, the first children who come in line to ride the swing get to
ride it first.

1.4.2

Shortest Job First

The shortest job first algorithm makes sure that the process with the shortest CPU burst is
executed first. For example, if processes with CPU burst times of 10, 5, 3, 2, 4 are in the ready
queue, then the process with burst time of 2 would be chosen to run on the CPU.

Shortest Job First has been mathematically proven to give the shortest possible waiting time
for any group of processes already in the queue. However, if additional processes arrive, then
the solution is no longer optimal.
Consider our previous example: P1, P2, P3, P4, and P5 with CPU burst of 100, 1, 1, 1, 1. If all
these processes arrive at the same time, then the order of execution would be P2, P3, P4, P5
and P1 last, giving an optimal average wait time of 2 seconds. However, if P2 through P5 arrive
at time 5, after P1 has already been chosen for execution, then there would be no choice but
to wait for P1 to finish, producing a significantly longer wait time.
Following our analogy, children who would want to ride the swing for a short amount of time
get priority.

1.4.3

Shortest Remaining Time Next

The shortest remaining time left is similar to SJF scheduling, but allows for pre-emption. If a
process with a shorter CPU burst arrives than the one currently running on the CPU, the OS
suspends the process on the CPU and gives control to the newly arrived process with the short
CPU burst.
Note that this decision is made only when a new process arrives in the ready queue. If no new
processes arrive then the process on the CPU is allowed to run until it finishes.
A point of contention occurs when using the process execution table if SJF comes with a
context switch time. When does process selection occur, before the context switch time or after
the context switch time?
This situation becomes prominent when a process with a short CPU burst arrives during the
time that a context switch occurs. To illustrate this case, consider processes P1, P2 are
processes with burst time 5, and 7 arriving at time 0. Then, process P3 arrives at time 3 with
burst time 2, and P4 arrives at time 5 with burst time 1. The following would be the process
execution table if we assume a context switch time of 3 seconds.
Scheduling: Shortest Job First with context switch time of 3 seconds
Processes: P1 (5), P2 (7) at time 0, P3 (2) at time 2, P4 (1) at time 5

Operating Systems

J.E.D.I.

Time

CPU

Ready Queue

Comment

P1 (5)

P2 (7)

P1, P2 arrives. P1 chosen to run

P1 (4)

P2 (7)

Idle (3)

P3 (2), P1 (3), P2 (7)

P3 arrives. Context switch time

Idle (2)

P3 (2), P2 (3), P3 (7)

Context switch time

Idle (1)

P3 (2), P2 (3), P3 (7)

Context switch time

???

P4 (1), P3 (2), P1 (3), P2 (7)

P4 arrives (contention P4 vs P3)

At time 2, P1 (3) is on the CPU. At the same time, P3 (2) arrives. Since we are using shortest
remaining time first, P3 should replace P1 on the CPU.
So from time 2 to 4, the CPU undergoes context switch, saving P1 information and loading P3
information. At the end of the context switch time, P3 (2) should run on the CPU. However, P4
(1) has an even shorter burst time.
So if process selection occurred at time 2 before context switch, then P3 should run on the CPU
at time 5 even if P4 has a shorter burst. However, as we would really want to run the job with
the shortest remaining time left, P4 should be the one to run. In fact, if we follow the
algorithm, there would be a context switch immediately after time 5, when P4 replaces P3.
To make things simple for our discussion, we will make process selection at the end of the
context switch time. And, as we keep our ready queue sorted according to shortest burst time,
then process selection would simply be running the process at the head of the queue when
context switch time ends.

1.4.4

Priority

Priority queues arranged processes according to a pre-established priority scheme. Processes


with higher priority are made to run first. By our playground analogy, Grade 5 children would
have priority to the swing than the Grade 1 kids (because they are bigger and may beat you
up).
In most computer systems, some processes are more important than others. For example, the
mouse pointer process has to be given highest priority over any other process: you want your
mouse to move all the time regardless if an application is busy. Same thing goes for the
keyboard.
Traditionally, lower numbered priority is higher (Priority 1 processes are much more important
than Priority 10). Priority scheduling can come with or without preemption. If priority
scheduling has preemption, then the currently running process will be evicted from the CPU if a
process with a higher priority arrives.
For example, we have processes P1, P2, P3 with burst time 2, 4, and 3 with priorities 10, 5,
and 1 all arriving at time 0. To describe a process with a priority, we will represent priority as a
value p, and time left as a value t. For example, P1 (p=10,t=3).
Scheduling: Priority without preemption
Processes: P1 (p=10,t=2), P2 (p=5,t=4), P3 (p=1,p=3) at time 0
Time

CPU

Ready Queue

Comment

P3 (p=1,t=3)

P2 (p=5,t=4) P1 (p=10,t=2)

P1, P2 and P3 arrives, P3 chosen

P3 (p=1,t=2)

P2 (p=5,t=4) P1 (p=10,t=2)

Operating Systems

J.E.D.I.

P3 (p=1,t=1)

P2 (p=5,t=4) P1 (p=10,t=2)

P2 (p=5,t=4)

P1 (p=10,t=2)

P2 (p=5,t=3)

P1 (p=10,t=2)

P2 (p=5,t=2)

P1 (p=10,t=2)

P2 (p=5,t=1)

P1 (p=10,t=2)

P1 (p=10,t=2)

P1 (p=10,t=1)

1.4.5

P3 ends, P2 chosen

P2 ends, P1 chosen
Simulation ends

Priority with Aging

The problem with priority scheduling is the possibility of a process being unable to run because
it keeps on being passed over by higher priority processes. In computer history, there is a
rumor that when they shut down the MIT IBM 7094 computer in 1973, they found a process
that was submitted in 1967 and had not yet been run because its priority was too low and was
never chosen by the scheduler1.
To counter this problem, processes which were not chosen by the scheduler to run are given a
slightly higher priority. This is called process aging. Over a long enough time span, even a very
low priority process will gain enough priority to be chosen to run next.

1.4.6

Round-robin

The round-robin scheme is the one of the most widely used scheduling algorithms. The roundrobin scheme revolves around the idea of a time quantum. The time quantum is how long a
process can run on the CPU before execution is given to another process in the ready queue.
For example, we are given P1 (20), P2 (30), P3 (15) and P4 (10) arriving at time 0 with time
quantum of 10 seconds.
Fig 4-9

Using our playground analogy, a teacher gives each child 2 minutes on the swing before its
time to give the swing to someone else. If the kid wants to go on the swing again, he or she
will have to line up again.
When we consider a context switch time with the round-robin scheme, then having a small
time quantum size can have a detrimental effect on CPU utilization. Having a shorter time
quantum means having more context switches. And the more often context switches occur,
then the more often the CPU is left idle while processes are being switched.
On the other extreme, having a long time quantum duration makes the round-robin
degenerate into a basic FCFS scheduling algorithm.

1 Silberscatz, Galvin. Operating System Concepts, 5th edition.


Operating Systems

J.E.D.I.

1.4.7

Multiple Queues

Operating Systems actually use a combination of scheduling algorithms, placing processes on


multiple queues, each with its own scheduling scheme, with a priority scheme used to select
between queues.
Following our playground analogy, the children could all line up by grade level, one line for
Grade 1 students, one line for Grade 2 and so on. A grade level may have their own scheme
per line: FCFS for Grade 1, Round Robin for Grade 2, etc. Once each grade level has decided
who goes to the head of the line, the teacher chooses from which line the next student to play
on the swing comes from.
A simple scheme, found in some UNIX systems, is the use of two queues: a foreground or
interactive queue and a background or batch queue. When processes start, they would be
assigned a queue automatically via some characteristic of the process. Users can even run
commands in order to assign processes either to the foreground or background queue. The
foreground queue may use a round robin scheme, while the background queue uses a FCFS
scheme in choosing the process that comes at the head of the line. The kernel then chooses
between each queue, giving higher priority to the foreground queue.

The Solaris scheduling scheme has 6 such queues or scheduling classes: the Timeshare,
Interactive, Fair-share scheduler, Fixed Priority, System and Real-time scheduling classes.
Timeshare is the default scheduling class for processes. Process priorities in this queue are
adjusted in order to optimize resource usage. It aims to divide CPU usage fairly among users.
If there are three users logged on, then the processes from a single user gets chosen 1/3 of
the time. Of course processes of that user would have to share in that 1/3 of CPU time,
whether the user has 1 process or many.
The Interactive scheduling class applies to the processes involved with the actively selected
application in the GUI. As the currently running GUI application is most probably interacting
with the user, then processes in this queue would have slightly higher priority on the CPU and
with other system resources.
Timeshare and Interactive queues use a round-robin scheduling scheme with an adaptive timequantum. It also adjusts the priority of I/O bound processes, increasing their priority so that
they could finish with their short CPU burst faster, leaving the CPU bound processes more time
to run on the CPU while the I/O bound processes wait for slower I/O. The interactive scheduler
simply places an additional 10 priority to processes that are associated with the active window
in the GUI, providing a better response time to users.
Fixed Priority scheduling class are for processes that the user does not want to change priority
as the other queues would dynamically change process priority.

Operating Systems

10

J.E.D.I.

The Fair-share scheduler improves on the Timeshare queue as it gives CPU time based on the
concept of CPU shares. Using Solaris commands, an application can be given a certain number
of CPU shares. The amount of CPU time that processes belonging to that application is based
on what percentage of total CPU shares that application has.
For example, if an application has 10 shares and the total number of allocated CPU shares is
100, then that application gets 10% of CPU time. Any application with zero CPU shares will not
be granted CPU time until all applications with shares are finished.
The Fair-share scheduler, however, does not work well with the Timeshared, Fixed priority or
Interactive scheduling queues. The Fair-share scheduler is a special scheduling algorithm which
is recommended to be assigned to a processor all by itself as combining this scheduling
algorithm with other queues on the same processor may result in unexpected behavior.
Processes in Solaris can have priority numbers from 0 to 169, with 169 being the highest
priority. If a process has priority 0-59, it is assigned to one of the queues discussed above.
Kernel processes, with priority 60-99 are placed in the System scheduling class. Kernel
processes cannot preempt other kernel processes, even if they have a higher priority.
The final queue is the real-time queue. Processes with priorities 100-169 fall into this queue.
Processes in the real-time queue have fixed-priority, with a fixed time quantum. Because they
have the highest priority, they can preempt kernel threads. Real-time threads need to have
this high a priority level because they operate with a very fixed time constraint and their task
may fail if they do not meet the deadline.

1.4.8

Multilevel Feedback Queue Scheduling

The multi-level feedback queue scheduling scheme has multiple queues, but these queues are
interconnected, processes leaving one queue enters the next one.
For example, consider the following multi-level queue. The first queue where processes enter
has a time quantum of 4. The second queue has a time quantum of 16. The last queue is a
FCFS queue.

Process execution happens this way. A process enters the first queue. If the process is not
finished with its CPU burst before the time quantum of 4 runs out, it is preempted and placed
in the second queue with a longer time quantum. If it still does not finish after 16 seconds,
then its placed in the FCFS queue.
The OS gives the first queue highest priority, this allows for processes with short CPU bursts or
Operating Systems

11

J.E.D.I.

I/O bound processes to be finished quickly. If the process has a longer CPU burst, then it is
placed in the second queue. The second queue has lower priority but gets to have longer time
at the CPU when it is chosen. If its longer time quantum runs out, then the process gets
migrated to the final FCFS queue. Although it has the lowest priority, it is no longer preempted
until it finishes its CPU burst.

Operating Systems

12

You might also like