4003-440/4003-713 Operating Systems I Process Scheduling Warren R. Carithers (wrc@cs.rit.edu) Rob Duncan (rwd@cs.rit.edu)
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.2
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.3
CPU Burst Times Typical distribution of CPU burst lengths: OS1.4
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.5
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.6
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.7
FIFO/FCFS FIFO/FCFS: jobs run in order of arrival, oldest first Example mix: Job Runtime A 24 B 3 C 4 Assume all are in ready queue at decision time Can show execution with Gantt chart: 0 A B C 24 27 31 n TAVG = Ti / n = = i = 1 W i /n = 0 24 27 /3=51/3=17 = W n AVG i=1 ( 24 + 27 + 31) / 3 = 82 / 3 27. 33 OS1.8
FIFO/FCFS If arrived B-C-A: T AVG = W AVG = n i=1 n i=1 0 B C A 3 7 31 T i /n = 31 3 7 /3=41 /3=13. 66 W i /n = 7 0 3 /3=10 /3=3. 33 Arrival order can have dramatic effect on performance: Order Avg. Turnaround Avg. Wait A-B-C 27.33 17 B-C-A 13.66 3.33 OS1.9
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.10
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.11
Exponential Averaging Definitions: t n =actual length of n th CPU burst τ n = predicted value for the n th CPU burst α = relative weight of past and recent history, 0 α 1 Then: τ n 1 =α t n 1 α τ n When α =0 τ n 1 =τ n Behavior does not count all predictions are the same When α =1 τ n 1 =t n Only the actual last CPU burst counts ignores older behavior OS1.12
Prediction of the Length of the Next CPU Burst Example, α = 1 2 and τ 0 =10 τ n 1 =α t n 1 α τ n OS1.13
Highest Ratio Next HRN: calculate response ratio for each job in queue: R= Wait Service Service 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.) OS1.14
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 4 4 1 4 0 2 3 1 0 2 3 0 1 2 3 OS1.15
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.16
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.17
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.18
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.19
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: process time = 10 quantum length context switches 0 10 12 0 0 6 10 0 1 2 3 4 5 6 7 8 9 10 6 1 1 9 OS1.20
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.21
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.22
RR, q = 50 0 100 200 300 400 475 550 650 750 850 950 1100 1200 1275 0 1 2 3 4 0 1 2 3 4 0 1 2 3 0 2 3 0 2 3 0 2 0 2 2 2 2 T AVG = 1100 550 1275 950 475 /5=4350 /5=870 W AVG = 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 C =0 200 175 125 100 100 50=750 0 W C AVG = 750 425 800 700 400 /5=3075/ 615 OS1.23
RR, q = 100 0 100 200 300 400 475 575 700 800 900 1000 1100 1200 1275 0 1 2 3 4 0 1 2 3 0 2 3 0 2 2 T W W AVG F C AVG AVG = = = ( 1100 + 600 + 1275 + 1050 + 475) / 5 = 4500/ 5 = ( 0 + 100 + 200 + 300 + 400) / 5 = 1000/ 5 = 200 ( 750 + 475 + 800 + 800 + 400) / 5 = 3225/ 5 = 645 900 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.24
RR, q = 50, s = 10 With q = 50, ignore I/O, context switch time is 10: 0 120 240 360 480 575 670 790 910 0 1 2 3 4 0 1 2 3 4 0 1 2 3 0 2 910 1030 1150 1270 1390 1510 1535 3 0 2 3 0 2 0 2 2 2 2 T AVG = 1320 660 1535 1140 565 /5=5220/5=1044 W F AVG = j0 60 120 180 240 /5=600/5=120 OS1.25
Turnaround Time Varies With The Time Quantum Quantum selection can have non-obvious effects: OS1.26
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.27
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.28
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.29
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 highest priority system processes interactive processes interactive editing processes batch processes lowest priority student processes OS1.30
Multilevel Feedback Queue Like MLQ, but jobs move between queues CPU quantum expiration block or suspend OS1.31
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.32
Example of MLFQ Three queues, all FCFS: Q 0 time quantum 8 ms Q 1 time quantum 16 ms Q 2 no quantum Scheduling New job enters queue Q 0 Q 0 is dispatched when not empty Q 0 job receives 8 ms quantum = 8 quantum = 16 quantum = If it does not finish, job is moved to queue Q 1 Q 1 is dispatched only if Q 0 is empty Q 1 job receives 16 ms If it still does not finish, it is moved to queue Q 2 Q 2 is dispatched only when Q 0 and Q 1 are empty Job runs until it terminates or it blocks May also preempt if new job arrives into Q 0 OS1.33
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.34
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 realtime 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.35
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 OS1.36