Purpose: make progress for all processes (fairness), and make progress for interactive processes (responsiveness)
Who should schedule:
It's fine to give higher priority to I/O bound processes (they will soon transit to I/O wait)
It's bad to give higher priority to CPU bound processes (they will keep running and starve I/O bound processes)
Criteria:
admin view: maximize utilization (busy-ness), throughput (job/sec)
process view: minimize turnaround time, waiting time (runnable but not running)
user view: PREDICTABLE response time (responsiveness), minimize response time
Four opportunities to schedule:
running process blocks (I/O, page fault, wait())
running process exits
blocked process becomes runnable (I/O completion, signal())
interrupt (timer interrupt, I/O interrupt)
Fully preemptive: all four Cooperative: only first two
Algorithms:
FCFS (bad): first come first serve (no preemption)
SJF (bad): shortest job first (can't know job length)
Priority (bad): will starve least important task (could be fixed by priority aging)
Round-Robin: each task run fixed amount of time (fair but not "provably optimal" due to balance between "fairness" vs "context switch cost")
Multi-level + feedback queue: round-robin on each priority level, and we can promote process when aging / reward for I/O.
Load Balancing (multi processor)
Processor affinity (multi processor)
Hyperthreading: one physical computational unit but two register/memory set, and the computational unit switch between two register/memory set quickly (and don't switch when one is I/O blocked). This only speedup in certain cases, and hurt performance in other cases. It also has security bugs based on timing attacks.
Realtime Scheduling: (e.g. for self-driving car, delay can cause death)
Soft-realtime scheduling: (e.g. UI, video games, video streaming, etc.)
Table of Content