Scheduling Policies & MLFQ

Policy goals in tension

No single scheduler optimizes everything. Batch jobs want high throughput; interactive shells want low response time; real-time audio wants deadlines met. Production schedulers blend policies rather than picking one.

Classic policies (teaching baselines)

Policy	Behavior	Failure mode
FIFO / FCFS	First in, first out	Convoy effect behind slow job
SJF	Shortest job first	Starvation of long jobs; needs future knowledge
Round Robin	Fixed time slice, rotate queue	High turnaround for long CPU-bound jobs
Priority	Always run highest priority	Low-priority starvation

MLFQ — the intuition model

The Multi-Level Feedback Queue uses multiple priority queues:

1. New jobs start at highest priority.
2. Jobs that use their full time slice drop a level (CPU hogs sink).
3. Jobs that yield early (I/O-bound) stay high (interactive wins).
4. Periodic priority boost prevents starvation.

You don't need to implement MLFQ — but interviewers and OSTEP use it to explain why your SSH session stays snappy while a ffmpeg encode runs in the background.

Linux CFS in one paragraph

Completely Fair Scheduler (default SCHED_OTHER) tracks virtual runtime per thread in a red-black tree — the leftmost (least CPU time used) runs next. Nice values and cgroups cpu.max bias weights. Real-time policies (SCHED_FIFO, SCHED_RR) bypass CFS entirely — misuse can lock up the machine.

Senior-level signal

Setting SCHED_FIFO without understanding priority inheritance is how teams brick a production host. For normal services, tune thread pool size ≈ cores and let CFS work; pinning and RT policies are last resorts with clear measurement.

Where this goes next

Multicore, Cache Affinity & CPU Pinning explains why scheduler decisions on a 64-core box involve cache warmth and NUMA — not just fairness on a single run queue.