Process Scheduling

A lot of the material here is motivated by ch 6,7 in [Link]

Recall : Process states and
transitions
Running
(U)
syscall
sysret

Kernel scheduling
Ready Running

Terminal
Unblocked
Blocking Request

Opportunities
Blocked
context switch to
run another process
Context Switching
• We have seen how context can be saved and restored.
• Recall that the PCB holds the context when the process is not running.
• Goals of context switching from say process A to process B
• When process A terminated, then if a process B is ready
• When process A is running, but becomes blocked, then if a process B is ready.
• When process A is running, but it is out of its time quota, then if process B is
ready
• The aim is to make the CPU available to other processes on the
system….
What if it is a
uni/multi-processor
systems ?
The Run Queue and Scheduling
• All the processes that are in the ‘Ready’ state are candidates to be
given the CPU.
• These are put into a list or queue of some sort. This is called a Run
Queue.
• In some sense Scheduling is about organizing the run queue and
selecting processes from the run queue to be assigned to the CPU.
Scheduling processes on the CPU
CPU

• Scheduling is the method of

deciding which process to run at
a given point in time. Run queue 0
P1
• Objective of scheduling includes: P3 1
P1 P2
• Keeping the CPU utilization high P9 2
• Keeping the users/processes P3 P2 3
satisfied with their experience P3
• Fairness P4 P5 P6
4
• Quick response P8 P9 .
• Quick completion ... . t
.
P2
Simple Scheduling Metrics and Job
assumptions
• TAT (Turnaround time) = Completion Time – Arrival Time
• Some assumptions about processes that may or may not hold:
• A1: All processes have the same execution time, say 10s
• A2: Arrive at the same time
• A3: No preemption: once started, a process is given CPU till it is complete
• A4: No processes are blocked (e.g., they don’t perform IO)
• A5: We know the run time of each process
Simplest method would be to schedule jobs in the order in which they
arrive
FCFS or FIFO
• Just run processes as they arrive and run them to completion
• Equal execution times (10)
A B C • All arrive together (at t=0)
• No preemption
0 10 20 30 • No IO
• All times known
• Average TAT = 10+20+30 / 3 = 20, would be the same if order
changed

• What if we drop A1 – so if execution times are unequal:

A B C B C A
0 10 20 30 40 0 10 20 30 40
SJF – Being sensitive to the job
• Equal execution times
• All arrive together
• No preemption
length •
•
No IO
All times known
• If A1 doesn’t hold, then it is good to schedule shorter jobs early
B C A
0 10 20 30 40

• What if assumption A2 doesn’t hold – jobs can arrive any time? Then
even SJF wouldn’t be helpful

A B C
0 10 20 30 40 Cant do much unless we allow preemption

B and C arrive

A arrives
 • Equal execution times

STCF – Taking into account •

•
All arrive together
No preemption

preemption •
•
No IO
All times known

• If we additionally relax A3 – ie running jobs can be preempted then

we have a new possibility –

A B C Avg TAT=(30+30+40)/3=33.33
0 10 20 30 40 50
Preemption
B and C arrive

A B C A
A arrives
0 10 20 30 40 50

B and C arrive

A arrives Avg TAT=(50+10+20)/3=26.66

 • Equal execution times
• All arrive together

Response time •
•
No preemption
No IO
• All times known

• While the above is reasonable in a few situations, it is not suitable in

general.
• Not good where we have interactive jobs, the reason is we are not
measuring how responsive a system is.
• Each user would like to get the feeling that some progress is being
made on that user’s job.
• This introduces the notion of using time based preemption and
resumption… perhaps using time slices as the unit of scheduling.
 • Equal execution times

Preemption and the Response time •

•
All arrive together
No preemption

metric – Round Robin (RR) •

•
No IO
All times known

• For interactive processes it is important for the user to experience

some progress – This is what we commonly have in most General
Purpose OS setups. Response Time is the time to wait for CPU
access.

A B C Response Time = Time to first access to CPU

!
0 10 20 30 RT(A)=0, RT(B)= 10, RT(C) = 20 e off
a d
Tr
t ric
e
M
RT(A)= 0 , RT(B) = 1.66, RT(C ) = 3.3 c e
0 10 20 30 ti
N o
• Round Robin (time slicing) is the simplest form of preemptive
scheduling to reduce response time
Round Robin’s unintended overhead
• Context switch overhead
• Cache line inefficiency
• Paging inefficiency
•…

• So one needs to balance the time slice size appropriately.

• Too small means we have too much overhead/ inefficiencies
• Too large means we increase response time
 • Equal execution times

Overlap of I/O and CPU - •

•
All arrive together
No preemption

Blocked Processes •
•
No IO
All times known

• Most processes at some point in time will do IO

• IO is significantly slow.
• If a process is waiting for IO (hence blocked from making progress) it makes a lot
of sense to let the CPU be used by other processes
• A process could be blocked for other reasons too.
• Thus each IO request is an opportunity to switch CPU to another process.

A B C One might of course combine :

• IO overlap
0 10 20 30 • FIFO and Round Robin too
CPU-- A B C • With RR we don’t need
to know process times
IO-- 0 10 20 30
 • Equal execution times
• All arrive together

In a general context •
•
No preemption
No IO
• All times known

• Some of A1-A5 are reasonable in real-time systems.

• So FCFS with IO overlap is quite reasonable
• Often we can use a combination Round-Robin and overlapping IO and
execution in other systems.
• In general there could be a combination of different kinds of
processes:
• Time-critical processes, perhaps with deadlines (real-time)
• CPU bound processes (insignificant IO)
• Interactive processes (significant IO and/or user interaction)
 Priorities in Scheduling

• In addition to the above, we may want to explicitly prioritize some

processes for execution
• This is often the case with real-time systems.
• Each process is given a priority. A higher priority process is given more
CPU time than a lower priority process.
• Nice values are an example of this. The nice value is translated to a priority.
 Multi Level Queues for scheduling
with per-process fixed priorities
To deal with multiple
priority jobs
• Associate priority with each process [Hi] Q8 A B High prio
• Create a queue of processes ? Reat time
Q7
according to the priorities Low prio
• Rule 1 if Priority(P) > Priority(Q) then Q6 C D
Run P Q5
• Rule 2 if Priority(P) = Priority(Q) then
Run them in Round Robin Q4

• Rule 3 new processes are inserted in Q3

the appropriate queue
Q2
Non time-
[Lo] Q1 E critical
In Linux the scheduling policies RR and FIFO use these ideas
Linux Real-Time Scheduling – NOT
for normal processes
• In Linux they use the term “Scheduling policy”
• Two real-time scheduling policies are:
• Round Robin (SCHED_RR policy) and (run for fixed time slices)
• First-in-First-out (SCHED_FIFO policy) (run till completion)
• 100 priority levels, higher priority process is always run before lower priority level process
• Within a priority level FIFO is prioritized over RR
• Need superuser previlages to set and reset real time priority levels - chrt(1) command.
• Normal process are under SCHED_OTHER policy and are lower priority than the above but still
allocated a guaranteed small fraction of CPU time (like 5% - configurable)
• See some examples sched_*.c in the repository – and know the system calls to change policy
and priority.
• Todo - Play with chrt(1) to see some interactive examples.
• Normal processes are scheduled using the CFS scheduler, also referred as SCHED_OTHER policy
in Linux commands
Multi Level Feedback Queue based
If we don’t know
which processes
Scheduling (priority change over
should get a priority
to give better TAT,

time) while improving RT

• A process is allotted a certain time [Hi] Q8 A B

according to its priority.
• Create a queue of processes according to Q7
the priorities
Q6 C D
• Rule 1 if Priority(P) > Priority(Q) then Run P
• Rule 2 if Priority(P) = Priority(Q) then Run Q5
them in Round Robin
• Rule 3 new processes are at the highest Q4
priority
Q3
• Rule 4 Reduce the priority of a process
based on how much time it uses up. Q2 E

• Rule 5 Periodically boost the priority of all

[Lo] Q1
processes
Linux Fair scheduling (CFS) for normal processes –
NOT for real-time processes – Simplified explanation
1. Linux decided it would be fair to all processes and be responsive
• Idea is to consider a maximum latency (say L) – so every process must get the CPU once in L units of time
for sure.
• Let the number of ready to run processes be N
• Then we give 1/N * L as a first estimate of the time slice to each process (notice this depends on N and L)
2. Take into account the nice value
• For each nice value assign a numeric weight w. – TODO: use renice or nice to play with nice values
• Now compute the time slice for a process as: ie the maximum latency is still L, however higher priority
processes still get a larger slice.
3. However each process is given a minimum slice time guarantee. This implies L is at least
4. Now prioritize by maintaining a vruntime for processes indicating howmuch time they have
spent on the CPU.
1. This is updated when the process is running by timer ticks and also when the process blocks.
(update_curr)
5. To read more, see: [Link]
Linux Real-Time Scheduling … but
with a deadline
• SCHED_DEADLINE is used to schedule jobs with
• A periodic execution
• A deadline to react (sometimes same as period)
• A required guaranteed run time before that deadline

• Execution is expected to be interleaved with other processes with

other scheduling policies.

• For those interested, see : [Link]

Adding more fairness - Groups
• Some times it is important that a bunch of
Experiment: See effect of autogroup:
processes belonging to one user or one 1. Have three terminals.
session do not consume all the CPU. 2. Run top in the first terminal.
3. In the second terminal start three
• So CPU is allocated to process groups – for instances of a busy loop in the
example all processes of a user or all background. (./loopy busy &)
4. In another terinmal just start one
processes from one terminal. instance. (./loopy busy)
• The intention is that one set of processes 5. What does top show?

do not consume all the resources among

themselves, instead it is available to all
users in a fair fashion.
• These groups can be nested. See
autogroups created in a shell for example.
Notion of Time in the OS
• Notion of a “tick”
• It is a unit of time used in the kernel for its notion of time.
• Also called a Jiffy in Linux
• The CPU is interrupted every jiffy and it increments a jiffies counter
• Hardware interrupt is provided by an external timer (like a PIC, multiple possibilities)
• Linux Jiffy configuration and use:
• There is a kernel constant called HZ or CONFIG_HZ HZ = 1000 means
• Number of times a second that the CPU is interrupted CPU interrupted each 1/1000 s
i.e. once each
millisecond
• This is used to control how often the timer is interrupted
• Important from a scheduling point of view
• At each timer interrupt the amount of time used by a process is accounted.
If required the scheduler is also called.
Critical sections and scheduling
• Sometimes, processes compete to access resources.
• The resources (eg shared resources like files)are guarded by some
software artifacts and called critical sections
• They are ‘critical’ and guarded because it would only be reasonable
for one process to be in that code at the same time – else we the
processes step over each other leading to bad(unintended)
consequences.
• More details later
Scheduler behavior with critical
sections
• Dealing with Critical sections
• Simplistic approach: A process in a critical section is not be preempted
• A better approach: Preempting is ok, but use some form of blocking when a
later process arrives
• The later arrivers discover the CS is in use
• They wait
• Critical sections are small, so maybe blocking is not a problem.
• Let’s now look at this behavior in the case of the FIFO real-time
scheduler where processes have priorities
FIFO with priority based preemption

P1

0 1 2 3 4 5 6 7 8 9
-Code--
-----------
---CS------
--------
-------
 FIFO with priority based preemption
P2 arrives P2 finishes/
exits

1. P2 arrives in [0 3] it preempts P1
Hi P2

Lo P1

0 1 2 3 4 5 6 7 8 9
-Code--
-----------
Premption. ---CS------
P1 waits now until P2 finishes --------
-------
 FIFO with priority based preemption

1. P2 arrives in [0 3] it preempts P1
Hi P2 2. P2 arrives in [4 7] it preempts P1
provided P2 does not need the CS

Lo P1

0 1 2 3 4 5 6 7 8 9
-Code--
-----------
---CS------
Premption. --------
P1 waits now until P2 finishes -------
 FIFO with priority based preemption

1. P2 arrives in [0 3] it preempts P1
Hi P2 2. P2 arrives in [4 7] it preempts P1
provided P2 does not need the CS
3. P2 arrives in [4 7] and it wants to execute CS
then it blocked until P1 finishes its CS.
So P1 is scheduled
Lo P1

0 1 2 3 4 5 6 7 8 9
-Code--
Premption. ----------- P2 enters CS once P1 is
P1 waits now until P2 wishes ---CS------ done
to enter the common CS P2 blocks and because --------
P1 is already in the CS, -------
So P2 executes
 FIFO with priority based preemption

1. P2 arrives in [0 3] it preempts P1
Hi P2 2. P2 arrives in [4 7] it preempts P1
provided P2 does not need the CS
3. P2 arrives in [4 7] and it wants to execute CS
Med P3 then it blocked until P1 finishes its CS.
So P1 is scheduled
Lo P1 4. What happens if P3 comes in between?
5. Note that P3 can in effect block P2,
0 1 2 3 4 5 6 7 8 9 thus getting more priority.
“PRIORITY INVERSION”
-Code--
-----------
---CS------
Preemption: --------
-------
Priority inversion
• This is a peculiar phenomenon where a lower priority process can make the higher
priority process wait unreasonably long.
• It happens because of the need to have ‘critical sections’
• Critical sections are code where only one process can be executing at a time. Thus multiple
processes are excluded from entering at the same time.
• More about critical sections later.
• It also happens because of the way FIFO policy treats priorities
• One way to deal with it is called Priority Inheritence:
• A process running the CS temporarily inherits/gets the priority of the highest priority process
which is blocked on the CS
• In our example P1 running in the CS would inherit P2’s priority when P2 blocks on the CS
• Thus P3 can’t preempt P1
• P1 returns to original priority the moment it exits the CS
Summary Process Scheduling
• Process states and transitions
• What is a background process?
• What are zombie processes and how to create them.
• Re-parenting of (orphaned) processes
• How to change the priority of processes?
• Different scheduling strategies
• Different scheduling metrics TAT and RT
• Priorities and scheduling policies in Linux.
• System calls: fork(), exec(), wait(), getting and setting scheduler policy and process priority
information.
• Examples show how to change priorities and scheduling policies on Linux.
• Priority Inversion
• Please see example code on gthub under procs/
The end of the topic of
Process Management