Topics Process CPU Scheduling SGG9 ed 6 1

Topics: Process (CPU) Scheduling (SGG[9 ed] 6. 1 -6. 3) (SGG[older ed] 5. 1 -5. 3) CS 3733 Operating Systems Instructor: Dr. Turgay Korkmaz Department Computer Science The University of Texas at San Antonio Office: Phone: Fax: e-mail: web: NPB 3. 330 (210) 458 -7346 (210) 458 -4437 korkmaz@cs. utsa. edu www. cs. utsa. edu/~korkmaz These slides are prepared based on the materials provided by Drs. Robbins, Zhu, and Liu. Thanks to all. 1

Outline z Reviews on processes and their states z Process queues and scheduling events z Different levels of schedulers Ø CPU Scheduler Ø Preemptive vs. non-preemptive Ø Context switches and dispatcher Ø Models and assumptions for CPU scheduling Ø CPU-bound and IO-bound processes z Performance criteria Ø Fairness, efficiency, waiting time, response time, throughput, and turnaround time; z Classical schedulers: FIFO, SFJ, RR, and PR z CPU Gantt chart vs. process Gantt charts 2

Reviews z Process Ø Execution of program z States of Process Ø New and terminated Ø Running (R) using CPU Ø ready (r) in memory, ready for the CPU Ø waiting (w) waiting for I/O device or interrupt What may cause a process to move out of the CPU? 3

When to move out of CPU? z I/O request Ø Need to read/write data from/to a file (on disk) z Invoke a system call (e. g. , exit, fork, wait) Ø fork() creates a new process Ø fork() returns to both parent/child processes with different return values; Not every system call results in context-switch ü Parent gets child process ID while Child gets 0; z An interrupt or signal Ø Timer interrupt (quantum time) Ø Signal Ø Other synchronization like wait/join 4

Process Queues z Process state transition from one queue to another z Job queue (before process gets into main memory) Ø All processes in mass storage (disk) waiting for allocation of memory (non-demand-paging system) z Ready queue Ø In main memory waiting for the CPU Ø Usually a linked list is used to manage PCBs of all processes in the ready queue 5

Process Queues (cont. ) z Device queues Ø One for each device containing all processes waiting for it Ø Disk drives, tape drives, and terminals Ø Shareable devices (disk drives): may have processes Ø Dedicated devices (tape drives): have at most one process 6

Process Queues (cont. ) z Once the process is allocated the CPU and is executing, one of several events could occur: Ø I/O requests (e. g. , read/write data from/to files) Ø System calls (e. g. , create a new child process and wait for it) Ø Interrupts (forcibly removed from the CPU) z A process continues this cycle until it terminates, at which time it is removed from all queues and has its PCB and resources deallocated. o t ss e c xt? o pr ne ch ect i h el 7 W s

Different Levels of Schedulers z Long-term scheduler (or job n Short-term scheduler (or CPU scheduler) – selects which processes should be brought into process should be executed next the ready queue and allocates CPU Ø Less frequent l More frequent (e. g. , every 100 ms) Ø Controls degree of multiprogramming l Must be fast (if it takes 10 ms, then we have … ~10% performance degradation)

Different Levels of Schedulers z Short-term (CPU) scheduler Ø Selects which process from ready queue(s); Ø Must operate frequently and fast, several times a second z Medium-term scheduler (for time-sharing systems) Ø Swapping --- moving processes in and out of memory Ø Too many lots of paging with decreased performance z Long-term (job) scheduler Ø Decide which processes are admitted to the system Ø Determines the degree of multiprogramming Ø In stable conditions: invoke only when a process terminates Ø May take long time; for batch systems; may not be good for time-sharing systems; 9

CPU Scheduler z A process is migrated among various queues z Operating system must select (schedule) processes from these queues in some fashion. Ø The selection process is called as “Scheduler”. 10

When CPU Scheduler is Invoked? z 1. Process switches from running to waiting Ø Requests for I/O operations z 2. Process switches from waiting to ready Ø I/O completed and interrupt z 3. Process switches from running to ready Ø Due to timer interrupt z 4. Process terminates Ø When a process complete its work 11

Non-Preemptive vs. Preemptive z Non-preemptive scheduling: voluntarily give up CPU Ø The process having the CPU uses it until finishing or needing I/O Ø Not suitable for time-sharing Ø Only IO (case 1) and process termination (case 4) can cause scheduler action z Preemptive scheduling: system forcibly gets CPU back Ø Process may be taken off CPU non-voluntarily Ø Time-sharing systems have to be preemptive! Ø Both occasions 2 and 3 may cause scheduler action 12

Dispatcher and Context Switch z Dispatcher: gives control of CPU to selected process Ø Context switch Ø Setting the program counter (PC), and … PB Ø Save running state of the old process: where to save ? Ø Load the saved state of the new process: from where ? Ø A few microsecond to 100's of microseconds depending on hardware support C z Context Switch: switch CPU to another process 13

Context Switch z When CPU switches to another process, the system must save the state of the old process and load the saved state for the new process via a context switch z Context of a process represented in the PCB z Context-switch time is overhead; the system does no useful work while context switching z Hardware support Ø Multiple set of registers then just change pointers z Other performance issues/problems Ø Cache content: locality is lost Ø TLB content: may need to flush Not every system call results in context-switch

Process Model for CPU Scheduling z Model of Process Ø Cycle of (interleaving) CPU and I/O operations z CPU bursts: time to use CPU z I/O bursts: time to use I/O devices P 1 P 2 P 3 2 (one CPU burst) 8 8 4 4 6 (CPU + I/O bursts) (CPU, I/O, CPU) 15

Assumptions for CPU Scheduling z CPU model Ø By default, assume only a single CPU core Ø Exclusive use of CPU: only one process can use CPU z I/O model Ø Multiple I/O devices (so no waiting in IO queues!) ü !NOT IN PRACTICE! Ø Processes can access/request different I/O devices Ø I/O operation time of different processes can overlap 4 P 2 8 4 Ready Queue P 3 2 6 16

An Example: No Multiprogramming z Suppose 2 processes, where each process Ø Requires 20 seconds of CPU time Ø Waits 10 second for I/O for every 10 seconds execution 10 10 z How will they run without multiprogramming? Ø Run one after another 10 10 P 1 10 P 2 10 z How well do we utilize our CPU? Ø Out of 80 sec, CPU was busy for 40 sec Ø CPU utilization is about 40/80*100 = 50% 17

An Example: with Multiprogramming z Multiprogramming: both processes run together Ø The first process finishes in 40 seconds Ø The second process uses CPU (I/O) alternatively with first one and finishes 10 second later 50 seconds P 1 P 2 10 10 CPU utilization = ? 40/50*100 = 80% Total time: 50 seconds 18

Multiprogramming z Multiprogramming is a form of parallel processing in which several programs are run at the same time on a uniprocessor. Why? Objective? Maximize CPU utilization. When a process waits for IO, CPU time is wasted and no useful work is accomplished. So give it to another process! 19

CPU-bound vs. IO-Bound CPU-bound: spend more time on CPU, high CPU utilization Total CPU usage Process 1: CPU bound CPU bursts Process 2: I/O bound I/O waits Total CPU usage Time I/O-bound: spend more time on IO, low CPU utilization 20

Outline z Reviews on processes and their states z Process queues and scheduling events z Different levels of schedulers Ø CPU Scheduler Ø Preemptive vs. non-preemptive Ø Context switches and dispatcher Ø Models and assumptions for CPU scheduling Ø CPU-bound and IO-bound processes z Performance criteria Ø Fairness, efficiency (CPU Utilization), waiting time in ready queue, response time, throughput, and turnaround time; z Classical schedulers: FIFO, SFJ, RR, and PR z CPU Gantt chart vs. process Gantt charts 21

Performance Measures per process p We can measure the followings about each process p Ø Arrival time: Ø First time to respond: Ø Finish time: ta(p) tr(p) tf(p) Ø Turn around time (from submission to termination) tturn_around(p) = tf(p) - ta(p) Ø Response time tresponse_time(p) = tr(p) - ta(p) Ø Total waiting time in Ready queue twait_ready(p) +=(tp_taken_from_r_queue – tp_put_into_r_queue) Ø Total waiting time in IO queue Ø Total CPU burst time: twait_io(p) Ø Total I/O burst time: tio(p) (0, we have multiple I/O !!!) tcpu(p) 22

Performance Measures for the system ta(p 1) tr(p 1) tf(p 1) ta(p 2) tr(p 2) tf(p 2) ta(p 3) tr(p 3) tf(p 3) z We can measure Ø Total time to finish all processes ttotal Ø Total time CPU was idle tidle Ø Total time spend for context-switch tdispatch 23

Performance Metrics involving all processes z Fairness Ø Each process gets a fair share of CPU in Multiprogramming z Efficiency: CPU Utilization (p) Ø Percentage of time CPU is busy; z Throughput Ø Number of processes completed per unit time (e. g. , 10 jobs per second) z Average Turnaround Time Ø Time from submission to termination ∑ all tturn_arround(p) ---------#of_processes 24

Performance Metrics involving all processes (cont. ) z Average Waiting time in Ready queue Ø Time for a process waiting for CPU in a ready queue z Average Response time Ø Time between submission and the first response Ø Good metric for interactive systems Ø Response time variance ü For interactive systems, response time should NOT vary too much ∑ all twait_ready(p) ---------#of_processes ∑ all tresponse_time(p) ------___------#of_processes 25

. Scheduling Goals z All systems Ø Fairness: give each process a fair share of the CPU Ø Balance: keep all parts of the system busy; CPU vs. I/O Ø Enforcement: ensure that the stated policy is carried out z Batch systems Ø Throughput: maximize jobs per unit time (hour) Ø Turnaround time: minimize time users wait for jobs Ø CPU utilization: CPU time is precious keep the CPU as busy as possible z Interactive systems Ø Response/wait time: respond quickly to users’ requests Ø Proportionality: meet users’ expectations z Real-time systems: correctness and in-time processing Ø Meet deadlines: deadline miss system failure! Ø Hard real-time vs. soft real-time: self-driving car control system vs. DVD player Ø Predictability: timing behaviors is predictable Max CPU utilization Max throughput Min turnaround time Min waiting time Min response time Usually NOT possible to optimize for all metrics with the same scheduling algorithm. So, focus on different goals under different systems 26

Exercise: Compute performance metrics Suppose all processes arrived at the same time t=0! And NO I/O Find turnaround, waiting, response time for each process. Then take their averages… n CPU utilization : What percent of the time the CPU is used n Throughput : Number of processes that are completed per time unit n Turnaround time : Amount of time to complete a process n Waiting time in Ready queue: Amount of time a process has been waiting in the ready queue n Response time : Amount of time it takes from when a request was submitted until the first response is produced 27

Outline z Reviews on processes and their states z Process queues and scheduling events z Different levels of schedulers Ø CPU Scheduler Ø Preemptive vs. non-preemptive Ø Context switches and dispatcher Ø Models and assumptions for CPU scheduling Ø CPU-bound and IO-bound processes z Performance criteria Ø Fairness, efficiency, waiting time, response time, throughput, and turnaround time; z Classical schedulers: FIFO, SFJ, RR, and PR z CPU Gantt chart vs. process Gantt charts 28

FIFO or (First In First Out) FCFS (First Come First Serve) : non-preemptive, based on arrival time SJF (Shortest Job First) : preemptive & non-preemptive PR (PRiority-based) : preemptive & non-preemptive RR (Round-Robin) : preemptive SCHEDULING ALGORITHMS Deciding which of the processes to select from the ready queue!

. Scheduling Policy vs. Mechanism z Separate what should be done from how it is done Ø Policy sets what priorities are assigned to processes Ø Mechanism allows ü Priorities to be assigned to processes ü CPU to select processes with high priorities z Scheduling algorithm parameterized Ø Mechanism in the kernel Ø Priorities assigned in the kernel or by users z Parameters may be set by user processes Ø Don’t allow a user process to take over the system! Ø Allow a user process to voluntarily lower its own priority Ø Allow a user process to assign priority to its threads 30

First In First Out (FIFO) First-Come First Served (FCFS) z Ready Queue is strictly managed as FIFO Ø processes are added to queue based on arrival time Ø And executed in a non-preemptive manner. n CPU utilization : What percent of the time the CPU is used n Throughput : Number of processes that complete their execution per time unit n Turnaround time : Amount of time to execute a particular process n Waiting time: Amount of time a process has been waiting in the ready queue n Response time : Amount of time it takes from when a request was submitted until the first response is produced, not output (for time-sharing environment) z Suppose 3 processes arrive at t=0 in order Ø P 1: 24 (CPU burst time), P 2: 3, P 3: 3 Ø CPU Gantt chart shows which process uses CPU over time. Ø Average waiting time (in ready queue) = (0 + 24 + 27)/3 = 17 31

FIFO or FCFS: cont. z What if the 3 processes arrive in a different order Ø P 2: 3, P 3: 3, and P 1: 24 (CPU burst time) Ø CPU Gantt chart Ø Avg waiting time (AWT) = (0 + 3+ 6)/3 = 3 !!! Ø Big improvement of AWT over the previous case! Problem of FCFS: long jobs delay every job after them. Many processes may wait for a single long job. Convoy effect: short process behind long process 32

Process Gantt Chart vs. CPU Gantt chart z For each process, show its state at any time z For the last example with the original order Ø CPU Gantt Chart Ø Process Gantt chart R (Running), r (ready), w (waiting) 33

Another Example: CPU and I/O Bursts z Two processes z Process Gantt chart for FCFS - FIFO z AWT in ready queue = (0+9) / 2 = 4. 5 z Notes: Ø Waiting time in ready queue for process is the number of r's in the string Ø AWT is total number of r's divided by number of processes Ø CPU utilization is the total number of R's divided by the 34 total time (the length of the longer string)

Shortest Job First (SJF) z SJF: run the job with the shortest CPU burst first! z Example of 4 processes Ø CPU Gantt chart vs. Process Gantt chart Ø AWT in ready queue = (0+3+9+16)/4 = 7 z Which job has the shortest CPU burst in practice? Ø Use past history to predict: Ø Suppose that is predicted time, and t is actual run time Ø _(n+1) = a*t_n + (1 -a)* _n exponential average 35

Shortest Job First (SJF): cont. z Example 3: SJF ØProcess Gantt chart z Average waiting time: Ø P 1: waits for 6 (r) units first, then CPU, then I/O, and CPU Ø P 2: runs for 6, does I/O, waits for 5 (r) units, and CPU Ø AWT = (6 + 5)/2 = 5. 5 SJF is optimal means that it gives minimum average waiting time for a given set of processes 36

Preemptive Shortest Job First (PSJF) z So far, we considered non-preemptive SJF z But it can be Preemptive, too! How? Ø If a new process enters the ready queue that has a shorter next CPU burst compared to what is expected to be left (remaining) of the currently executing process, then Ø Current running job will be replaced by the new one z Shortest-remaining-time-first scheduling z Example 3 ØProcess Gantt chart z AWT = (8+0)/2=4 37

Round Robin Scheduling (RR) z Non-preemptive: process keeps CPU until it terminates or requests I/O z Preemptive: allows higher priority process preempt an executing process (if its priority is lower) z Time sharing systems Ø Need to avoid CPU intensive processes that occupy the CPU too long z Round Robin scheduler (RR) Ø Quantum: a small unit of time (10 to 100 milliseconds) Ø Processes take turns to run/execute for a quantum of time Ø Take turns are done in FIFO or FCFS 38

RR Examples z RR with quantum of 4 Ø AWT = (6+4+7)/3 = 17/3 = 5. 67 z RR with quantum of 3 Ø AWT = (6+6)/2 = 6. 0 Typically, higher average turnaround than SJF, but better response 39

RR: Round Robin Scheduling + Quantum z If quantum is small enough Ø For n processes, each appears to have its own CPU that is 1/n of CPU’s original speed Ø What could be the poblem with too small quantum? z Quantum: determines efficiency & response time z How to decide quantum size? 10 to 100 ms Ø Too small too many context switches no useful work Ø Too long response time suffers Ø Rule of thumb: 80% of CPU bursts <= quantum 40

PR (PRiority Based Scheduling) z Assign a priority to each process Ø “Ready” process with highest priority allowed to run Ø Can be preemptive or nonpreemptive Ø Same priority: use FIFO z Priorities may be assigned dynamically High “Ready” processes Priority 1 Priority 2 Priority 3 Priority 4 Low Ø Reduced when a process uses CPU time Ø Increased when a process waits for I/O 41

Summary of CPU Scheduling Algorithms z FIFO or FCFS : non-preemptive, based on arrival time Ø - Long jobs delay everyone else z SJF : preemptive & non-preemptive Ø + Optimal in terms of waiting time z PR : preemptive & non-preemptive Ø + Real-time systems: earliest deadline first (EDF) z RR : preemptive Ø + fairness, Processes take turns with fixed time quantum (e. g. , 10 ms) z Multi-level queue (priority classes) Ø System processes > faculty processes > student processes z Multi-level feedback queues: change queues Ø short long quantum 42

Multilevel Queues (Express lanes) z Ready queue is partitioned into separate queues: foreground (interactive), background (batch) z Each queue has its own scheduling algorithm Ø foreground – RR Ø background – FCFS z How to do scheduling between the queues? Ø Fixed priority scheduling; ü Serve all from foreground then from background ü Possibility of starvation. Ø Time slice (Weighted Queuing (WQ)) ü Each queue gets a certain amount of CPU time which it can schedule among its processes; • 80% to foreground in RR • 20% to background in FCFS + simple - Not flexible - Starvation if PR sch is used

Multilevel Feedback Queues z A process can move between the various queues based on CPU burst characteristics Ø CPU bound move into low priority queue Ø I/O bound move into high priority queue z Aging can be implemented this way to avoid starvation z Multilevel-feedback-queue 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 z Most flexible and general, but hard to configure

Example of Multilevel Feedback Queue z Three queues: Ø Q 0 – RR with time quantum 8 milliseconds Ø Q 1 – RR time quantum 16 milliseconds Ø Q 2 – FCFS z Scheduling Ø A new job enters queue Q 0 which is served FCFS. When it gains CPU, job receives 8 milliseconds. If it does not finish in 8 milliseconds, job is moved to queue Q 1. Ø At Q 1 job is again served FCFS and receives 16 additional milliseconds. If it still does not complete, it is preempted and moved to queue Q 2. Ø Processes requiring less than 8 ms will be served quickly…

Exercises: CPU Scheduling q 4, q 5, and this 46

Exercise: multilevel queue 47

Summary z Reviews on processes and their states z Process queues and scheduling events z Different levels of schedulers Ø CPU Scheduler Ø Preemptive vs. non-preemptive Ø Context switches and dispatcher Ø Models and assumptions for CPU scheduling Ø CPU-bound and IO-bound processes z Performance criteria Ø Fairness, efficiency, waiting time, response time, throughput, and turnaround time; z Classical schedulers: FIFO, SFJ, RR, and PR z CPU Gantt chart vs. process Gantt charts 48

REST is OPTIONAL UNIX SCHEDULING

UNIX Scheduling Algorithm z Also use multi-level feedback queues z A runnable process get a number which queue z Lower numbers higher priority Ø Negative numbers: system processes cannot be killed by signals z First process in the lowest nonempty queue run Ø nice to reduce priority z Time quantum of 0. 1 second (100 milliseconds) z Priorities are re-calculated once a second z Non-preemptive except for quantum expiration 50

UNIX Scheduling Algorithm (cont. ) z Some flavors of Unix interactive process with window focus gets highest priority z A process’ user-mode priority Ø p_usrpri = P_USER +. 25 * p_cpu + 2 * p_nice Ø p_cpu : increased each time the system clock ticks and the process is running Ø p_cpu is adjusted once per second for ready processes using a digital decay filter Ø Load sampled average length of run queue for previous 1 minute interval of system operations 51

UNIX Scheduling Algorithm (cont. ) z When a process is blocked for an event, it cannot accumulate CPU time z When a process sleeps for more than 1 second Ø p_slptime is an estimate of how long it is blocked z Non-preemptive process running in kernel mode Ø Not suitable for real-time systems 52

Linux Scheduling Algorithm z Use two separate scheduling algorithms Ø One for time-sharing with focus on fairness Ø One for real-time tasks with absolute priorities Priorities and Time-slice length z Time sharing processes: based on a credit system Ø Process has a fixed priority and variable number of credits Ø To choose a process the one with most credits to run Ø Running process loses one credit per timer interrupt, which is removed from CPU when its credits run out Ø If no process has any credits = credits/2 + priority 53

Linux Scheduling Algorithm (cont. ) z Real-time processes have higher priority than time-sharing processes Ø Time-sharing tasks run only if no runnable real-time tasks z Real-Time Scheduling Ø Each process has a priority and a scheduling class Ø Scheduling class: can be FIFO = FCFS or RR z z The highest priority real-time task runs first For tasks with the same priority: FCFS For FCFS, a process runs until its I/O operation RT processes do NOT preempt other processes 54