Introduction
Thrashing is a condition in a virtual-memory system where the CPU spends most of its time servicing page faults (moving pages in and out of memory via the disk) instead of doing useful work. It happens when the combined memory demand of the running processes exceeds the physical frames available, so each process is constantly stealing frames from the others, causing a cascade of page faults across the whole system.
Cricket analogy: Thrashing is like a ground staff constantly relaying the pitch cover on and off between overs due to threatening rain, spending more time moving equipment than the match spends actually being played.
Explanation
The root cause of thrashing is over-commitment of the degree of multiprogramming: the OS lets too many processes run concurrently for the amount of physical memory available. Each process needs a certain 'working set' of pages resident to make progress without constantly faulting. When physical frames per process drop below that working set size, every process faults frequently; the OS then spends CPU time and disk bandwidth swapping pages rather than executing instructions, and CPU utilization drops sharply even though the scheduler sees a full ready queue and mistakenly tries to admit even more processes -- which makes thrashing worse, not better. Two standard fixes exist: the working-set model, which tracks the set of pages each process referenced in its most recent time window (the working-set window) and only runs a process if enough frames are available to hold its whole working set; and page-fault frequency (PFF) control, which monitors each process's fault rate directly and reduces (or increases) its allocated frames, or suspends processes, to keep the rate within an acceptable band. In both cases, the ultimate remedy is reducing the degree of multiprogramming -- swapping out one or more processes entirely -- so the remaining processes have enough frames to run without excessive faulting.
Cricket analogy: Over-committing the degree of multiprogramming is like a franchise fielding too many trialists at once so each gets only a few balls of net practice, far short of the reps (working set) needed to actually improve, and the ground just churns through swaps.
Example
/*
* CPU utilization vs. degree of multiprogramming
*
* Degree of CPU
* multiprogramming utilization
* --------------- -----------
* 5 20%
* 10 55%
* 15 80% <- healthy peak
* 20 90%
* 25 60% <- thrashing begins here
* 30 15% <- severe thrashing
*
* As more processes are admitted past the healthy peak, each
* process gets fewer frames than its working set requires.
* Fault rate per process rises sharply, so the CPU spends most
* cycles handling faults (disk I/O wait) instead of running
* instructions -- utilization collapses even though more
* processes are "active".
*
* Working-set example: window size = 5 references.
* Reference stream for process P: ... 1 2 3 4 2 1 5 6 2 1 2 3 7 ...
* At the point after reference "6", the working set (last 5 refs
* 4 2 1 5 6) = {1,2,4,5,6} -> needs 5 frames resident to avoid
* faulting again soon. If P only holds 2 frames, it will keep
* faulting -- a local symptom of the system-wide thrashing problem.
*/Analysis
The key diagnostic signal for thrashing is the combination of high disk (paging device) activity with low CPU utilization -- a naive scheduler that reacts to low CPU utilization by admitting more processes will make thrashing dramatically worse, since it further shrinks each process's frame allocation. The correct response is the opposite: reduce the degree of multiprogramming (suspend or swap out some processes) so that each remaining process can hold its working set in memory, which raises CPU utilization back toward the healthy peak. This is why the working-set model and page-fault-frequency control are described as admission/allocation policies, not replacement algorithms -- they operate one level above page replacement, deciding how many frames each process deserves and how many processes should run at all.
Cricket analogy: The correct diagnosis is like a captain noticing the scoreboard barely moves despite fielders sprinting everywhere; the fix isn't adding more fielders but reducing chaos, e.g., resetting the field placements, not overcrowding it further.
Key Takeaways
- Thrashing = processes spend more time page-faulting (I/O bound) than executing (CPU bound); CPU utilization drops even though many processes are 'ready'.
- Root cause: too high a degree of multiprogramming for the available physical frames, so no process holds enough of its working set.
- Naively admitting more processes to raise low CPU utilization worsens thrashing -- this is the classic anti-pattern to recognize.
- The working-set model tracks recently referenced pages within a sliding window and only schedules a process if its working set fits in memory.
- Page-fault-frequency (PFF) control adjusts frame allocation, or suspends processes, based on directly measured fault rates.
- The fix is always to reduce the degree of multiprogramming (swap out processes) until each remaining process gets enough frames.
Practice what you learned
1. What is thrashing in the context of virtual memory?
2. What is the most common root cause of thrashing?
3. If CPU utilization is low and a naive scheduler responds by admitting more processes, what typically happens?
4. What does the working-set model use to decide how many frames a process needs?
5. What is the definitive fix once a system is thrashing?
Was this page helpful?
You May Also Like
Page Replacement Algorithms
How an OS decides which page to evict on a page fault when all frames are full, compared via FIFO, LRU, and Optimal.
Virtual Memory Concepts
The abstraction that gives each process its own address space, which can be larger than physical RAM.
Demand Paging
Lazy loading of pages into memory only when referenced, and the step-by-step page-fault handling sequence that makes it work.