An OS notices CPU utilization has dropped to 3% despite having many active processes. Processes are constantly blocked waiting for I/O. What is the most likely cause, and what is the correct response?
AThe CPU is mostly idle — admit more processes to increase utilization and throughput
BThrashing — too many processes competing for too few frames; suspend some processes to free their frames for the remaining ones
CThe page replacement algorithm is choosing poor eviction victims; switch to LRU
DThe disk is the bottleneck; upgrading to an SSD will solve the problem
Low CPU utilization combined with constant I/O blocking is the signature of thrashing: processes are spending all their time waiting for pages to be swapped in from disk, not executing instructions. Option A is the classic wrong response — the OS might see low CPU utilization and admit more processes, but this makes thrashing catastrophically worse by further dividing the insufficient frames. The correct fix is to reduce multiprogramming: suspend processes entirely to free their frames, allowing the remaining processes to each hold their working sets. Option C is wrong because no replacement algorithm helps when frames are simply insufficient.
Question 2 Multiple Choice
The working set model defines a process's working set W(t, Δ) as...
AAll pages the process has ever accessed during its entire lifetime
BThe maximum number of frames the OS should ever allocate to this process
CThe set of pages referenced by the process within the last Δ time units
DPages currently loaded in physical memory that belong to this process
The working set is a sliding window over recent memory references: W(t, Δ) is the set of distinct pages referenced in the interval (t−Δ, t). This captures the process's current locality — the pages it actively needs right now, not all pages it has ever used. The window size Δ must be tuned carefully: too small and the working set misses pages the process will need momentarily; too large and it includes stale pages from an earlier execution phase. The key use of the working set is to determine minimum frame allocation: a process needs at least |W(t, Δ)| frames to run without excessive faults.
Question 3 True / False
When a system is thrashing, the correct response is to reduce the degree of multiprogramming by suspending processes, not to switch to a better page replacement algorithm.
TTrue
FFalse
Answer: True
Page replacement algorithms (LRU, FIFO, Clock) choose which page to evict when a fault occurs — they assume frames are scarce and do the best possible with what exists. But thrashing occurs precisely when total frame demand exceeds total supply: no replacement algorithm can conjure frames that don't exist. The only real fix is to reduce demand by suspending one or more processes, freeing their frames. A better replacement algorithm reduces fault *rate* within a given allocation; it cannot solve the fundamental over-commitment that causes thrashing.
Question 4 True / False
During thrashing, CPU utilization is very high because the CPU is constantly busy handling page fault interrupts.
TTrue
FFalse
Answer: False
This is the counterintuitive part of thrashing: CPU utilization collapses. When processes are thrashing, they spend almost all their time blocked waiting for pages to be swapped in from disk. The CPU is sitting idle while the disk does endless swap I/O. The system appears slow AND underutilized simultaneously. This is what makes thrashing easy to misdiagnose: low CPU utilization looks like there's spare capacity, tempting the OS to admit more processes — exactly the wrong response.
Question 5 Short Answer
A system begins thrashing. Explain why reducing the degree of multiprogramming solves the problem when better page replacement algorithms cannot.
Think about your answer, then reveal below.
Model answer: Thrashing occurs because the sum of all active processes' working set sizes exceeds available physical frames — there simply aren't enough frames to satisfy everyone's locality needs simultaneously. Page replacement algorithms choose optimally among bad options (which page to evict), but they cannot create new frames. Reducing multiprogramming by suspending processes frees their entire frame allocation, allowing the remaining processes to each hold their working sets in memory. Each remaining process can now run without constant faulting, and total useful throughput rises even though fewer processes are 'active.'
The key insight is that thrashing is a supply/demand problem, not an allocation strategy problem. Page replacement is an allocation strategy; it works within a fixed supply. The working set model addresses supply: it tells the OS how much supply each process needs, and if total need exceeds supply, the OS must reduce demand (suspend processes) rather than reallocate the insufficient supply.