How MLFQ Approximates Shortest Job First (SJF)
How MLFQ Approximates Shortest Job First (SJF)
Let us now examine a more realistic and slightly more complex scenario to understand how the Multi-Level Feedback Queue (MLFQ) scheduler attempts to approximate Shortest Job First (SJF) without knowing job lengths in advance.
Scenario Description
We consider two jobs:
-
Job A
-
Long-running
-
CPU-intensive
-
Has already been running for some time
-
Currently resides in the lowest-priority queue
-
-
Job B
-
Short-running
-
Interactive
-
Requires only 20 ms of CPU time
-
Arrives later, at time T = 100
-
What Happens When Job B Arrives?
Step-by-Step Execution
-
Before T = 100
-
Job A is running continuously
-
Because it has consumed significant CPU time, it has been demoted to the lowest-priority queue
-
-
At T = 100
-
Job B arrives
-
According to MLFQ rules, new jobs are placed in the highest-priority queue
-
-
After T = 100
-
Job B immediately preempts Job A
-
Job B runs in the highest-priority queue
-
Job B completes execution in two time slices (20 ms total)
-
-
After Job B Completes
-
Job A resumes execution
-
Job A continues running at low priority
-
Conceptual Timeline
-
Black region → Job A (long-running, CPU-bound)
-
Gray region → Job B (short, interactive)
Job B finishes quickly without ever being pushed to lower-priority queues.
Why This Approximates SJF
MLFQ does not know job lengths ahead of time. Instead, it follows this strategy:
-
Assume every new job is short
-
Give it high priority
-
Observe its CPU usage:
-
If it finishes quickly → it was short
-
If it keeps using the CPU → gradually demote it
-
In This Example:
-
Job B truly is short
-
It finishes before being demoted
-
Job A, being long-running, stays at low priority
Thus, Job B effectively behaves as if it were scheduled by SJF.
Key Insight
MLFQ approximates SJF by learning from execution behavior rather than relying on prior knowledge.

Comments
Post a Comment