Download CPU Scheduling: Understanding Process Prioritization in Operating Systems and more Slides Computer Numerical Control in PDF only on Docsity!
CPU Scheduling
Arvind Krishnamurthy
Spring 2004
CPU Scheduling
Question: dispatcher can choose any thread on the ready queue to run; how to decide and which to choose?
n Depends on scheduling policy goals n minimize response time : elapsed time to do an operation (or job) n Response time is what the user sees: elapsed time to n echo a keystroke in editor n compile a program n run a large scientific problem
n maximize throughput : operations (jobs) per second n two parts to maximizing throughput n minimize overhead (for example, context switching) n efficient use of system resources (not only CPU, but disk, memory, etc.)
n fair : share CPU among users in some equitable way
n Example: Process Exec. Time P 1 24 P 2 3 P 3 3
n Suppose that the processes arrive in the order: P 1 , P 2 , P 3 The schedule is:
n Waiting time for P 1 = 0; P 2 = 24; P 3 = 27 n Average waiting time: (0 + 24 + 27)/3 = 17 n Average response time: (24 + 27 + 30)/3 = 27
P 1 P 2 P 3
0 24 27 30
First Come First Served
FCFS scheduling (cont’d)
Suppose that the processes arrive in the order
P 2 , P 3 , P 1.
n The time chart for the schedule is:
n Waiting time for P 1 = 6 ; P 2 = 0 ; P 3 = 3 n Average waiting time: (6 + 0 + 3)/3 = 3 n Average response time: (30 + 3 + 6)/3 = 13
n FCFS Pros: simple; Cons: short jobs get stuck behind long jobs
P 2 P 3 P 1
0 3 6 30
Example of preemptive SJF
Process Arrival Time Exec. Time P 1 0.0 7 P 2 2.0 4 P 3 4.0 1 P 4 5.0 4
n SJF (preemptive)
n Average waiting time = (9 + 1 + 0 + 2)/4 = 3
n Average response time = (16 + 5 + 1 + 6)/4 = 7
P 1 P 2 P 3
0 2 4 11
P 4
5 7
P 2 P 1
16
n CPU–I/O Burst Cycle
n CPU burst distribution
Alternating CPU and I/O Bursts
Round Robin (RR)
n Each process gets a small unit of CPU time ( time
quantum ). After time slice, it is moved to the end of the
ready queue.
Time Quantum = 10 - 100 milliseconds on most OS
n n processes in the ready queue; time quantum is q
n each process gets 1/ n of the CPU time in q time units at once. n no process waits more than ( n -1) q time units. n each job gets equal shot at the CPU
n Performance
n q large ⇒ FCFS n q too small ⇒ throughput suffers. Spend all your time context switching, not getting any real work done
RR with time quantum = 20
Process Exec. Time P 1 53 P 2 17 P 3 68 P 4 24 n The time chart is:
n Typically, higher average turnaround than SJF, but better fairness.
P 1 P 2 P 3 P 4 P 1 P 3 P 4 P 1 P 3 P 3
0 20 37 57 77 97 117 121 134 154 162
Multilevel queue
n Ready queue is partitioned into separate queues:
n Each with different priority
n OS does RR at each priority level
n Run highest priority jobs first n Once those finish, run next highest priority etc n Round robin time slice increases (exponentially) at lower priorities
n Adjust each job’s priority as follows:
n Job starts in highest priority queue n If time slice is fully used when process is run, drop one level n If it is not fully used, push up one level
n CPU bound jobs drop like a rock, while short-running I/O
bound jobs stay near top
n Still unfair – long running jobs may never get the CPU
n Could try to strategize!
Handling dependencies
n Scheduling = deciding who should make progress
n Obvious: a thread’s importance should increase with the importance of those that depend on it. n Naïve priority schemes violate this (“Priority inversion”)
n Example: T1 at high priority, T2 at low
n T2 acquires lock L. T1 tries to acquire the same lock.
n “Priority donation”
n Thread’s priority scales w/ priority of dependent threads n Works well with explicit dependencies
Lottery Scheduling
n Problem: this whole priority thing is really ad hoc.
n How to ensure that processes will be equally penalized under load? n How to deal with priority inversion?
n Lottery scheduling
n give each process some number of tickets n each scheduling event, randomly pick ticket n run winning process n to give P n% of CPU, give it ntickets * n%
n How to use?
n Approximate priority: low-priority, give few tickets, high-priority give many n Approximate SJF: give short jobs more tickets, long jobs fewer. If job has at least 1, will not starve
Lottery Scheduling Example
n Add or delete jobs (& their tickets) affects all jobs proportionately short job: 10 tickets; long job: 1 ticket
#short jobs/ % of CPU each % of CPU each #long jobs short job gets long job gets 1 / 1 91% 9% 0 / 2 NA 50% 2 / 0 50% NA 10 / 1 10% 1% 1 / 10 50% 5%
n Easy priority inversion: n Donate tickets to process you’re waiting on. n Its CPU% scales with tickets of all waiters.
