/ Operating Systems I. Process Scheduling. Warren R. Carithers Rob Duncan

4003-440/4003-713 Operating Systems I

Warren R. Carithers ([email protected]) Rob Duncan ([email protected])

Process Scheduling

OS1.2 Review: Scheduling Policy

• Ideally, a scheduling policy should:

• Be: fair, predictable

• Balance load

• Maximize: throughput, CPU utilization

• Minimize: overhead, turnaround time, waiting time, response time

• Degrade gracefully under heavy loads

• Failure to meet these goals can cause starvation (a.k.a.

indefinite postponement) of a process

• Scheduler can base its decisions on many factors:

• Past behavior of process

• Urgency

• Priority

• Origin (batch, interactive)

OS1.3 Measuring Scheduler Performance

• The following are criteria used to measure performance:

• CPU utilization

• Fraction of total available CPU time which is actually used by processes

• Throughput

• # of processes that complete their execution per time unit

• Turnaround time

• Time from process entry into ready queue until it finishes execution

• Waiting time

• Amount of time a process has been waiting in the ready queue

• Response time

• Time from when a request is submitted until the first response is produced

• Note: not necessarily the first output (for time-sharing environment)

OS1.4 CPU Burst Times

• Typical distribution of CPU burst lengths:

OS1.5 CPU Scheduler

• The scheduler selects from among the processes in memory that are ready to execute, and allocates the CPU to one of them

• CPU scheduling decisions take place when a process:

1. Switches from running to waiting state 2. Switches from running to ready state 3. Switches from waiting to ready

4. Terminates

• Scheduling is nonpreemptive if the CPU is never forcibly removed from a process

• Run-to-completion is the classic example (#4)

• Some debate about #1 if CPU is yielded voluntarily

• Scheduling is preemptive if the CPU can be taken away

• #2, #3 are typical examples

OS1.6 Dispatcher

• Dispatcher module gives control of the CPU to the process selected by the short-term scheduler

• This involves:

• Switching context

• Switching to user mode

• Jumping to the proper location in the user program to restart that program

• Dispatch latency – time it takes for the dispatcher to

stop one process and start another running

OS1.7 Non-Preemptive Algorithms

• CPU is never forcibly removed from a process

• Its simple!

• Predictable for a given job mix

• Algorithms:

• FIFO/FCFS

• Shortest Job First/Next (SJF/SJN)

• Highest Ratio Next (HRN)

• Deadline

• Priority

• To compare performance, we look at average waiting time and average turnaround time

• Waiting time: time between entry in system and dispatching

• Turnaround time: time between entry in system and termination

OS1.8 FIFO/FCFS

• FIFO/FCFS: jobs run in order of arrival, oldest first

• Example mix:

• Assume all are in ready queue at decision time

• Can show execution with Gantt chart:

Job Runtime

A 24

B 3

C 4

0

B C

A

24 27 31

( ^{24 27 31} ) ^{/ 3 82 / 3 27 . 33}

n / T

T

1 i

i

AVG

 = + + = =



 



=  ∑

=

W

=  ^∑

^W

 ^{/ n =  024 27  /} 3=51/ 3= 17

OS1.9 FIFO/FCFS

• If arrived B-C-A:

• Arrival order can have dramatic effect on performance:

0

B C A

3 7 31

T

=  ^∑

^T

 ^{/ n =  3137  /} 3=41 /3=13 . 66 W

=  ^∑

^W

 ^{/ n =  703  /} 3=10 /3=3 . 33

Order Avg. Turnaround Avg. Wait

A-B-C 27.33 17

B-C-A 13.66 3.33

OS1.10 Shortest Job First

• SJF: dispatch the job with shortest required runtime

• In previous example, B-C-A

• Unrealistic in real life – requires knowledge of run times of all jobs

• SJF gives best average wait times of any algorithm, preemptive or non-preemptive – why?

• If you select the “smallest” job, remaining jobs wait smallest amount of time

• So, at each selection point, we choose the job that will have the smallest effect on the waiting time of remaining jobs

• Problem: biased against long jobs – they’ll wait much longer than short jobs

• Especially problematic if new, shorter jobs continue to arrive while longer job sits in queue

• Problem: How do you determine job’s time?

• User input (trust input)? Prior experience on job type?

OS1.11 Approximating SJF

• Can’t implement “real” SJF

• No way to know the length of the CPU burst

• Could have user estimate length, but that’s problematic

• Can only estimate the length

• Can be done by using the length of previous CPU

bursts, using exponential averaging

OS1.12 Exponential Averaging

• Definitions:

• Then:

• When

• Behavior does not count – all predictions are the same

• When

• Only the actual last CPU burst counts – ignores older behavior

t

= actual length of n

CPU burst

τ

= predicted value for the n

CPU burst

α = relative weight of past and recent history, 0 ≤α ≤1

τ _n1 = α t _n   1− α  τ _n

α =0  τ

= τ

α =1  τ

=t

OS1.13 Prediction of the Length of the Next CPU Burst

• Example, α = 1

2 and τ

=10 τ

= α t

  1− α  τ

OS1.14 Highest Ratio Next

• HRN: calculate response ratio for each job in queue:

• Attempts to eliminate SJF bias against long jobs

• The longer a job sits in the queue, the higher its ratio gets

• At dispatch time, recalculate ratios, select job with highest ratio

• Takes time to recalculate

• “New” jobs will have Wait=0, so R=1 (lowest, by def.)

R= WaitService

Service

OS1.15 Deadline

• Deadline: time by which job must be finished

• If not finished, imposes hardship on user

• Scheduler must dispatch jobs in an order that guarantees jobs will finish by their deadlines

• Requires more anticipation by scheduler  more scheduling overhead

• Users must closely estimate job requirements

• Scheduler must run jobs without degrading performance of other jobs

• May be more than one sequence that satisfies deadlines

Job Runtime Deadline

0 350 575

1 125 550

2 475 1050

3 250 None

4 75 200

0

1 4 2 3

0

1 2 3

4

0 1 2 3

4

OS1.16 Priority

• Associate a priority with each job

• Some systems use low value for high priority; others, the reverse

• Schedule according to priority value

• Priorities can be:

• Internal – derived from process behavior

• External – input from user (i.e., from outside the scheduler)

• Priorities can be:

• Static – assigned once when process enters the system, never changed

• Dynamic – recalculated periodically; can vary with process behavior

OS1.17 Priority

• Variation: purchased priorities

• Assumes some type of charge scheme in use

• Pay extra (e.g., 110% of normal) for higher priority

• Receive discount (e.g., 90% of normal) for lower priority

• Problem: low priority processes may never execute

• Starvation

• Solution: aging – as time progresses, increase the priority

OS1.18 Non-Preemptive Algorithms: Problems

• All (except FIFO/FCFS) require knowledge of runtime

• User estimate: what if it’s wrong – e.g., user underestimates in order to gain scheduling advantage

• System estimate: based on what?

• Bad for interactive use

• No ability to take process behavior into consideration

• Sharing the CPU among all ready processes can

eliminate these problems

OS1.19 Preemptive Algorithms

• Preemption: CPU can be forcibly taken from process

• Preemptive schedulers rely on interval timer

• Unit of execution time: quantum

• Also known as time slice length

• Quantum length is critical to performance

• Jobs run until preempted, blocked, or suspended

• Higher avg. turnaround time, but better response time

• Algorithms:

• Shortest Remaining Time (SRT)

• Round Robin (RR)

• Multi-Level Queues (MLQ)

• Multi-Level Feedback Queues (MLFQ)

OS1.20 Quantum Selection

• Selection of quantum q is critical

• q too large  approaches FIFO (except preempt on block/suspend)

• q too small  context switch overhead is too high

• Relationship between quantum and context switching:

0 10

0 6 10

0 1 2 3 4 5 6 7 8 9 10

process time = 10 quantum

length context switches

12 0

6 1

1 9

OS1.21 Shortest Remaining Time

• SRT is a preemptive version of SJF

• Preemption based on arrival of new jobs, not on quantum expiration

• Idea:

• Preempt current process when new process arrives

• Use remaining service time, not original time, for comparison

• If new job has lower service time, it is dispatched (shortest runtime)

• If new job has greater runtime, “current” process is re-dispatched

• Guaranteed to have lowest service time of all jobs in the system

• Responds better to arrival of jobs than SJF/SJN

• Still suffers from postponement of long jobs

OS1.22 Round Robin

• RR: distributes CPU time evenly to all ready processes

• Preempt when:

• Quantum expires (“timer runout”)

• Process blocks for I/O

• Process suspends itself

• Additional complication: context switch time

• Not a problem in non-preemptive algorithms

• Affects all quantum-based preemptive algorithms

• Sample: Job Runtime

0 350

1 125

2 475

3 250

4 75

OS1.23 RR, q = 50

0 1 2 3 4 0 1 2 3 4

100 200 300 400 475

0 1

550

2 3 0 2 3 0 2 3

950 850

750 650

0 2 0 2 2 2 2

0 1100 1200 1275

T

=  11005501275950 475  / 5= 4350 /5=870 W

=  050100150200  / 5=500/5=100

• Note: this is wait until first service, not cumulative wait

• Cumulative wait must include waits between dispatches:

W

0

= 0 20017512510010050=750 W

AVG

=  750 425 800 700400  / 5= 3075/ ¿ 615

OS1.24 RR, q = 100

100 200 300 400 475 575 700 800 900 1000 1100

0 1200 1275

( )

( )

( ^{750 475 800 800 400} ) ^{/ 5 3225 / 5 645}

W

200 5

/ 1000 5

/ 400 300

200 100

0 W

900 5

/ 4500 5

/ 475 1050

1275 600

1100 T

AVG AVG

C F

AVG

=

= +

+ +

+

=

=

= +

+ +

+

=

=

= +

+ +

+

=

0 1 2 3 4 0 1 2 3 0 2 3 0 2 2

• Note that all the averages went up

• May not always be the case – depends on the job mix

• What have we ignored?

• I/O operations and other blocking events

• Context switch time

OS1.25 RR, q = 50, s = 10

• With q = 50, ignore I/O, context switch time is 10:

T

=  132066015351140565  / 5=5220/5=1044 W

AVG

=  j0 60120180 240  / 5= 600/5=120

0 1 2 3 4 0 1 2 3 4

120 240 360 480

0 1

575

2 3

3 2 0 3

2 0

910 790

670

0 2 0 2 2 2 2

0

1270 1150

1030

910 1390 1510 1535

OS1.26 Turnaround Time Varies With The Time Quantum

• Quantum selection can have non-obvious effects:

OS1.27 RR Variations

• Can schedule according to priority value

• Can use variable quantum – variations:

• Calculate quantum when job enters system, use for lifetime of job

• Calculate initial quantum when job enters system, periodically recalculate quantum according to job behavior

• Give temporary priority boost when process returns from being blocked (e.g., after I/O)

OS1.28 Multilevel Queue

• Idea: have more than one ready queue; associate a different priority with each

• Dispatch all within one level before any from next level

• On preemption, jobs return to same queue

CPU

OS1.29 MLQ

• Simplest form – two queues:

• Foreground (interactive)

• Background (batch)

• Each queue can have its own scheduling algorithm

• Scheduling must be done between the queues

• Fixed priority scheduling

• Serve all from foreground then from background

• Possibility of starvation for background jobs

• Time slice

• Each queue gets a certain amount of CPU time which it can schedule amongst its processes

• E.g., 80% to foreground, 20% to background

OS1.30 More Complex MLQ

• Associate a separate queue with each type of process

• Each queue has a priority associated with it

• Dispatch from highest to lowest priority

interactive processes interactive editing processes

system processes

batch processes student processes highest priority

lowest priority

OS1.31 Multilevel Feedback Queue

• Like MLQ, but jobs move between queues

CPU quantum expiration block or suspend

OS1.32 MLFQ

• A process can move between the various queues

• Can implement aging this way

• MLFQ scheduler defined by the following parameters:

• Number of queues

• Scheduling algorithms for each queue

• Method used to determine when to upgrade a process

• Method used to determine when to demote a process

• Method used to determine which queue a process will enter when that process needs service

• Example:

• Higher-level queues have smaller quanta; lower-level queues have larger quanta

• After I/O, job moves to higher-level queue

• After quantum expiration, job drops to lower-level queue

OS1.33 Example of MLFQ

• Three queues, all FCFS:

• Q₀ – time quantum 8 ms

• Q₁ – time quantum 16 ms

• Q₂ – no quantum

• Scheduling

• New job enters queue Q₀

• Q₀ is dispatched when not empty

• Q₀ job receives 8 ms

• If it does not finish, job is moved to queue Q₁

• Q₁ is dispatched only if Q₀ is empty

• Q₁ job receives 16 ms

• If it still does not finish, it is moved to queue Q₂

• Q₂ is dispatched only when Q₀ and Q₁ are empty

• Job runs until it terminates or it blocks

• May also preempt if new job arrives into Q₀

quantum =

∞

quantum = 16 quantum = 8

OS1.34 Multiple-Processor Scheduling

• More complex when multiple CPUs are available

• Homogeneous processors

• All are the same (e.g., within a multiprocessor system)

• Any process can run on any CPU

• Heterogeneous processors

• Some are different (e.g., within a distributed system)

• Each process can only run on certain CPUs

• Load sharing

• Attempt to balance load on all systems

• Asymmetric multiprocessing

• Only one CPU accesses the system data structures

• Alleviates the need for data sharing

OS1.35 Real-Time Scheduling

• Hard real-time systems – This is where there are

scheduling deadlines that the software absolutely must meet in order to maintain system operation. Failure to meet a hard deadline results in catastrophic system failure. A manufacture control system is an example of a system having hard real-time constraints.

• Soft real-time computing – This is where specific time constraints exist, e.g. event X must be handled every 10ms, but failure to do so isn't catastrophic and the system is able to recover if the deadline is missed.

Such failures shouldn't happen too often and the software should be designed to minimize that

possibility. An audio player, for example, has soft real-

time constraints on pulling data buffers for playback. If

a buffer isn't ready when it is needed, an audio glitch

occurs but the system continues to operate.

OS1.36 Algorithm Evaluation

• Deterministic modeling

• Takes a particular predetermined workload and defines the performance of each algorithm for that workload

• Queueing models

• Mathematical model of algorithm behavior

• Implementation

• The only truly accurate method