2.5 Scheduling
Given a multiprogramming system.
 Many times when more than 1 process is
waiting for the CPU (in the ready queue).
 The scheduler (using a scheduling
algorithm) decides which process will run
next.
 User satisfaction is important.

Context switch
When the CPU changes from one process to
another.
 Expensive operation.

User mode to kernel mode
2. Save state of current process
1.

3.
Run scheduler


4.
Registers, invalidate cache, MMU
Pick next process to run
Load state of next process
Run next process
Process
behavior

Types:
 I/O
bound – spend most time performing I/O
 Compute bound – spend most time
performing computation
 Mixture
When do we need to schedule?
creation (before/after parent?)
 exit
 block (I/O, semaphore, sleep, wait, etc.)
 I/O interrupt/completion
 clock interrupt

 non
preemptive (run until you block or
“cooperate”
 preemptive
Scheduling environments
Batch
 Interactive
 Real time

Scheduling algorithm goals
Concepts & definitions






Throughput = # of jobs completed per hour
Turnaround time = avg of “start (submit) to
completion” times; avg wait time
CPU utilization = avg of CPU busyness
Response time = time between issuing a
command and getting the result
Proportionality = user perception that “complex”
things take a long time and that is fine but
“simple” things must be quick
Predictability = regularity, especially important
for audio and video streaming
Batch scheduling
First-come first-served
 Shortest job first
 Shortest remaining time next
 Three-level scheduling

Batch scheduling

First-come first-served
 Simple
 Non
preemptive
 Process runs until it either blocks on I/O or
finishes
Batch scheduling

Shortest job first
 Optimal
turnaround time (when all start
together)
 Requires that we know run time a priori
Batch scheduling

Shortest remaining time next
 Preemptive
version of shortest job first
 Requires a priori information
 When a new job arrives, its total time is
compared to the current process’ remaining
time. If the new job needs less time to finish,
the new job is started.
 New, short jobs get good service
Batch scheduling

Three-level scheduling
 Admission
scheduler – chooses next job begin
 Memory scheduler – which jobs are kept in
memory and which jobs are swapped to disk
 How
long swapped in or out?
 How much CPU time recently?
 How big is the process?
 How important is the process?
 Degree
of multiprogramming – number of
processes in memory
 CPU scheduler – picks which runs next
Interactive scheduling
Round-robin scheduling
 Priority scheduling
 Multiple queues
 Shortest process next
 Guaranteed scheduling
 Lottery scheduling
 Fair-share scheduling

Interactive scheduling

Round-robin scheduling
 Simple,
fair, widely used, preemptive
 Quantum = time interval
 Process/context
switch is expensive
 Too small and we waste time
 Too large and interactive system will appear
sluggish
 ~20-50 msec is good
 Every
process has equal priority
Interactive scheduling

Priority scheduling
 Each
process is assigned a priority; process
with highest priority is next to run.
 Types: static or dynamic (ex. I/O bound jobs
get a boost)
 Unix/Linux nice command
Interactive scheduling

Ex. 4 priorities & RR w/in a priority
Interactive scheduling

Multiple queues
 Different
types
 Ex. 4 queues for:
 Terminal,
I/O, short quantum, and long quantum
Interactive scheduling

Shortest process next
 Shortest
job first always produces min avg
response time (for batch systems)
 How do we estimate this?
 From
recent behavior (of interactive commands, Ti)
 Example of aging (or IIR filter)


alpha near 1 implies little memory
alpha near 0 implies much memory
ˆ
Ti 1  Ti  (1   )Ti 1
Interactive scheduling

Guaranteed scheduling
 Given
n processes, each process should get
1/n of the CPU time
 Say we keep track of the actual CPU used vs.
what we should receive (entitled
to/deserved).
 K = actual / entitled
K
= 1  we got what we deserved
 K < 1  we got less than deserved
 K > 1  we got more than deserved
 Pick
process w/ min K to run next
Interactive scheduling

Lottery scheduling
 Each
process gets tickets; # of tickets can
vary from process to process.
 If you ticket is chosen, you run next.
 Highly
responsive (new process might run
right away)
 Processes can cooperate (give each other
their tickets)
Interactive scheduling

Fair-share scheduling
 Consider
who (user) owns the process
 Ex.
 User
A has 1 process
 User B has 9 processes
 Should
user A get 10% and user B get 90% or
should A get 50% and B get 50% (5.6% for each
of the 9 processes)? Latter is fair-share.
Real time scheduling



Time plays an essential role
Must react w/in a fixed amount of time
Categories:



Event types:



Hard – absolute deadlines must be met
Soft – missing an occasional deadline is tolerable
Periodic = occurring at regular intervals
Aperiodic = occurring unpredictably
Algorithm types:


Static (before the system starts running)
Dynamic (scheduling decisions at run time)
Real time scheduling
Given m periodic
events.
 Event i occurs w/
period Pi and requires
Ci seconds of CPU
time
m
 Schedulable iff:

(basically normalizing C by P)
Ci

1

P
i 1 i
Schedulable example
Given Pi = 100, 200,
and 500 msec
 Given Ci = 50, 30, 50 30 100


 0.5  0.15  0.2  0.85  1
100 200 500
100 msec


Can we handle
another event w/
P4=1 sec?

Yes, as long as
C4<=150 msec
50
30 100
?



1
100 200 500 1000
50
30 100 150



1
100 200 500 1000
Thread scheduling

User level threads
No clock interrupts (per thread)
 A compute bound thread will dominate its process but
not the CPU
 A thread can yield to other threads within the same
process
 Typically round robin or priority
+ Context switch from thread to thread is simpler
+ App specific thread scheduler can be used
- If a thread blocks on I/O, the entire process (all
threads) block

Thread scheduling

Kernel level threads
- Context switch from thread to thread is
expensive (but scheduler can make more
informed choices)
+ A thread, blocking on I/O, doesn’t block all
other threads in process