A system has 1000 physical frames. Five processes are running, and their working sets require 150, 200, 250, 180, and 300 frames respectively. The OS tries to keep all five running. What happens?
AThe system runs efficiently — 1000 frames is close enough to the total demand of 1080 frames
BThe system enters thrashing because total working set demand (1080 frames) exceeds available physical memory (1000 frames)
CThe OS automatically compresses the largest working sets to fit within 1000 frames
DPage fault rates increase moderately but performance stays acceptable with a good replacement algorithm
Total working set demand is 150+200+250+180+300 = 1080 frames, but only 1000 are available. Some process (or multiple processes) will be short on frames and page-fault constantly. While waiting for disk I/O, those processes block, the CPU appears idle, and the scheduler loads more processes — which are also short on frames. The system enters a vicious cycle where disk I/O dominates, CPU utilization collapses, and throughput falls catastrophically. No page replacement algorithm fixes a structural frame deficit.
Question 2 Multiple Choice
The OS detects thrashing. Which action best addresses the root cause according to the working set model?
ASwitch to LRU page replacement to better approximate the working set
BIncrease the page size so fewer frames are needed to hold the same data
CSuspend one or more processes entirely to reduce total working set demand below available physical memory
DIncrease the working set window Δ so each process has a larger, more stable resident set
Thrashing is a structural mismatch: total working set demand exceeds physical memory. Changing page replacement algorithms cannot fix this — the faulted pages are genuinely needed. Larger pages worsen internal fragmentation and don't solve the frame deficit. Increasing Δ makes each working set *larger*, worsening the mismatch. The only correct fix is to suspend one or more processes entirely, freeing their frames for the remaining processes so each active process can keep its working set fully resident.
Question 3 True / False
Thrashing can be solved by using a more sophisticated page replacement algorithm that keeps the most important pages in memory.
TTrue
FFalse
Answer: False
This is the core misconception about thrashing. Page replacement algorithms optimize within a given frame allocation — they decide which page to evict when a new one must be loaded. But thrashing occurs because the total number of frames is insufficient for all active working sets combined. Even a perfect oracle replacement algorithm cannot solve the problem: if a process needs 200 frames and has only 100, it will fault on every access to the other half of its working set, regardless of replacement strategy. The fix must be at the level of reducing the number of active processes.
Question 4 True / False
Temporal locality — the tendency for programs to reuse recently accessed pages — is the property that makes the working set concept useful as a predictor of future page demand.
TTrue
FFalse
Answer: True
The working set model depends on locality of reference: during any phase of execution, a program repeatedly uses only a small subset of its total pages (temporal locality), and those pages tend to be adjacent in address space (spatial locality). Because of temporal locality, the pages accessed in the last Δ time units are likely to be needed again in the next Δ time units. Without this property, the working set would change completely between measurements, making it useless as a prediction. Real programs exhibit strong locality due to loops, data structures, and function call patterns.
Question 5 Short Answer
Why does CPU utilization paradoxically drop toward zero during thrashing, even though the system appears fully loaded and active?
Think about your answer, then reveal below.
Model answer: During thrashing, processes spend almost all their time blocked waiting for disk I/O to satisfy page faults, not executing instructions. When a process page-faults, it blocks and the CPU idles. The scheduler, seeing the CPU idle, loads another process — which also immediately page-faults and blocks. Nearly all processes are simultaneously waiting for disk, the disk is flooded with page-fault requests, and the CPU has nothing runnable. CPU utilization is the fraction of time spent executing instructions, and since no process can execute until its pages are loaded, CPU utilization collapses.
This counterintuitive relationship — CPU utilization drops as system load increases beyond the thrashing threshold — is why CPU-only monitoring can miss thrashing. The correct diagnostic metrics are page fault rate, disk I/O queue depth, and I/O wait time. An OS monitoring working set sizes can detect when total demand exceeds physical memory before thrashing begins and preemptively suspend a process.