When Every Car Is Full
Every scheduling policy fancier than first-come-first-served earns its keep the same way: by having options to choose from. Given a queue, it picks which request to serve next, and it picks well, because there's more than one request sitting there to compare. That comparison is the whole mechanism. Take it away and the policy has nothing left to be clever about.
Disk-arm scheduling is the clean textbook case. First-come-first-served serves in arrival order, dragging the head back and forth across the platter however the queue happens to land. LOOK sweeps in one direction, picks off every request in its path, reverses at the last one, sweeps back. It's called the elevator algorithm for the obvious reason: same logic a lift uses to avoid darting to the ninth floor and back down to the second because two people pressed buttons in that order. The gain over first-come-first-served is proportional to something specific, the number of pending requests the algorithm gets to choose among at any given moment. More requests waiting, more comparisons available, more room to pick a smart order over an arbitrary one.
That room is really just slack, unclaimed capacity the policy converts into savings. A near-idle disk with one request queued has no slack to speak of. LOOK and first-come-first-served do the identical thing, because there's only one thing to do. A disk with a deep queue and requests scattered across the whole platter has plenty of slack, and that's where LOOK pulls ahead, because the order it's competing against is essentially random with respect to physical position, while LOOK's isn't.
Now push load up. Not busy, saturated: every slot spoken for, every request that could arrive has arrived, no idle interval anywhere. This is the condition everyone assumes is the real test, the stress case where you want the smart scheduler doing its job. It's also exactly the condition that deletes the resource the smart scheduler runs on. When the queue has to clear every request regardless, the total distance the head travels is bounded by the same thing for any reasonable policy, the physical spread of the requests themselves. LOOK still sweeps, first-come-first-served still drags, and their totals converge, because there's no longer a choice being made. There's a mandatory tour of every point in the queue, and any policy that doesn't waste motion on purpose ends up taking a similar route.
Call the thing that closes here the discretion budget. It's spent down every time the queue narrows toward one option and refilled every time it widens back out, and saturation is the state where it's permanently zero, because zero slack is what "full" means. Ask a scheduler to prove itself at the exact moment every resource is claimed, and you're asking it to perform in the one condition where its output and its dumbest competitor's output are structurally forced together.
The place the smart policy actually earns its name is the unglamorous middle: moderate load, some idle stretches, enough queued requests to make comparison worthwhile but not so many that comparison degenerates into "serve them all, order barely matters." Nobody benchmarks a scheduler on a slow Tuesday afternoon. They benchmark it during the traffic spike, because that's when it's supposed to matter most. But the spike is where the two algorithms shake hands.
None of this makes the clever policy pointless. Most systems spend most of their time away from full saturation, and the savings compound there in a way that's easy to undervalue precisely because nothing looks stressed while they're happening. It just means the instinct that ties smart scheduling to the worst case has the order backwards. The worst case is where the smartness runs out of anything to be smart about. What's left, once every car is full, is the queue itself, and everybody's going to the same floor eventually regardless of who decided the order.