A process enters the MLFQ scheduler and consistently uses its full CPU time quantum without voluntarily yielding. What happens to it over successive rounds?
AIt stays in the highest-priority queue because it clearly needs the most CPU time
BIt is terminated for monopolizing the CPU
CIt is demoted to a lower-priority queue with a larger time quantum
DIt is promoted to higher priority to ensure its long computation completes faster
A process that exhausts its full quantum is inferred to be CPU-bound (long-running). MLFQ demotes it to the next lower queue, which has a larger quantum but runs less frequently. This keeps CPU-hungry processes from starving interactive ones. The common misconception is that 'needing more CPU' should earn higher priority — but MLFQ rewards short, interactive bursts, not long ones.
Question 2 Multiple Choice
Why does a text editor waiting for keystrokes typically remain in the high-priority queues of an MLFQ scheduler?
AThe scheduler detects that the process is user-facing and assigns it a static high-priority flag
BI/O-bound processes receive special protection that prevents demotion
CThe process frequently yields the CPU before exhausting its time quantum, so the scheduler never demotes it
DText editors are given high priority by convention in most operating systems
MLFQ does not know the process is a text editor — it only observes behavior. Because the text editor spends most of its time waiting for keystrokes (an I/O event), it issues frequent I/O requests and voluntarily releases the CPU well before its quantum expires. The scheduler infers this is a short/interactive process and keeps it at high priority. No special flags or conventions are needed; the behavioral signal is the quantum usage pattern.
Question 3 True / False
MLFQ scheduling requires the operating system to know each process's expected run time before scheduling it.
TTrue
FFalse
Answer: False
This is precisely the problem MLFQ solves. SJF requires knowing burst times in advance, which is impractical. MLFQ observes behavior dynamically: processes that exhaust their quantum are inferred to be long-running and demoted; those that yield early are inferred to be short and kept at high priority. No advance knowledge is required.
Question 4 True / False
Without a periodic priority boost mechanism, MLFQ scheduling can cause starvation for long-running CPU-bound processes.
TTrue
FFalse
Answer: True
If interactive (high-priority) processes continuously arrive, they will always preempt lower-priority queues, leaving CPU-bound processes in the bottom queues to wait indefinitely. This is the starvation problem. The standard fix is a periodic priority boost: every fixed interval, all processes are moved back to the highest-priority queue, giving long-running processes a fresh chance to run.
Question 5 Short Answer
How does MLFQ approximate the behavior of Shortest Job First scheduling without knowing job lengths in advance?
Think about your answer, then reveal below.
Model answer: MLFQ uses observed CPU usage as a proxy for job length. New processes enter the highest-priority queue. If a process exhausts its quantum without yielding, the scheduler infers it is long/CPU-bound and demotes it. If it yields early (completing an I/O burst), it remains at high priority — inferred to be short/interactive. Short jobs naturally finish before demotion; long jobs sink to lower queues. The result is preferential treatment for short, bursty processes, mimicking SJF's behavior without requiring predictions.
This 'learn by observing' approach is more robust than SJF in practice because it adapts to actual behavior. A process that starts CPU-bound but later becomes interactive (e.g., a compiler that finishes compiling and starts waiting for user input) will be promoted back through the priority boost mechanism.