scheduling criteria

How do you tell a good scheduler from a bad one? You cannot just say faster, because faster for whom? A video render wants the machine cranking nonstop; a person typing wants the cursor to react instantly. Scheduling criteria are the handful of measurable yardsticks the OS designer uses to judge a scheduling policy, so the trade-offs can be discussed honestly instead of by feel.

The classic five: CPU utilization — what fraction of time the CPU is busy doing work (we want it high). Throughput — how many processes complete per unit time (high is good). Turnaround time — total time from a job's arrival to its completion (low is good). Waiting time — total time a job spends sitting in the ready queue, not running (low is good). Response time — the time from a request until the first response appears, which matters most for interactive use (low is good). Note that utilization and throughput are system-wide measures, while turnaround, waiting, and response are per-job and usually reported as averages.

The honest part: these goals conflict, so no policy can maximize all of them. Maximizing throughput may favor short jobs and hurt a long job's turnaround. Minimizing response time (with tiny time slices) raises context-switch overhead and can lower throughput. Real systems pick which criteria matter most for their workload — for a desktop, response time; for a batch cluster, throughput — and accept that the others suffer a little. Some settings also care about the worst case or the variance, not just the average, because a predictable system can be better than a slightly faster but jittery one.