Big idea
MLFQ is for when you *don’t* know how long jobs will run — the usual case that breaks the Chapter 7 policies that assume known runtimes.
How it works
Jobs sit in priority tiers (queues).
1. If Priority(A) > Priority(B), A runs (B does not) 2. If Priority(A) = Priority(B), A and B share the CPU with Round Robin 3. A new job starts at the highest queue 4. If a job uses its entire time slice, its priority is reduced 5. If a job gives up the CPU before the slice ends (e.g. I/O), priority stays the same 6. Periodically (every time S), boost everyone back toward the top queue
Long-running CPU hogs drift downward because they keep finishing their slices. Short / interactive work tends to stay high.
Gaming and starvation
A job can try to game the scheduler: use ~99% of a slice, then issue I/O so it never gets demoted. That starves honest long-running jobs of CPU.
Fixes discussed in the notes:
- Priority boost after time S — a refresh so low-priority work is not stuck forever. S is hard to tune: too short and interactive jobs lose cycles; too long and the system feels sticky.
- Rule 4 revised — once a job burns its allotment, demote it whether or not it voluntarily yielded the CPU. That closes the “fake I/O” loophole.