What problem does CPU scheduling solve, and what metrics do schedulers trade against each other?

🎤 Say this first

More runnable threads than cores — someone must decide who runs, for how long, and who waits. Schedulers juggle metrics that conflict: throughput (work/second) vs latency/response time (how fast an interactive task reacts) vs fairness (no one starves) vs efficiency (fewer context switches). Batch systems tilt to throughput; desktops and request-serving tilt to latency; real-time systems need guarantees, not averages. Preemptive scheduling (timer-driven) took over because cooperative scheduling let one buggy loop freeze the machine.

The full picture

Vocabulary to deploy precisely: turnaround time (submit→finish), response time (submit→first output), waiting time (time in ready queue), quantum/time slice, CPU-bound vs I/O-bound tasks.
The key behavioral insight: I/O-bound tasks use tiny CPU bursts then block — good schedulers effectively favor them (they yield early, they get dispatched quickly), keeping disks/NICs busy and interactivity snappy.
Preemptive vs cooperative: the timer interrupt is the OS's insurance policy against while(true). Cooperative scheduling survives today inside runtimes — event loops (Node, Netty) are cooperative, which is exactly why one blocking call on an event loop is a production incident.
Where you meet this as a backend engineer: p99 latency under load is a scheduling story — run-queue depth (load average beyond core count) means requests are waiting for CPU, not working.

🎤 Say this first

The full picture

🔄 Likely follow-up questions