Thrashing in Operating Systems: Meaning, Causes, Occurrence, and Prevention

Thrashing is a severe virtual memory performance failure in which the operating system spends most of its time moving pages between disk and RAM instead of running instructions.2 In practical terms, a process is said to be thrashing when it spends more time handling page faults than performing useful computation. This usually appears in demand-paged systems when the combined memory demand of active processes exceeds the available physical frames, causing repeated eviction and reloading of pages.2

Thrashing is tightly connected to locality of reference and the working set of a process.2 If a process does not have enough frames to hold its current locality, the next memory references are likely to fault again and again.2 When this happens across multiple processes, CPU utilization drops, disk I/O rises, and throughput can collapse rather than improve as system load increases.2

A useful formal view is the working-set criterion:

$$D = \sum_i WSS_i$$

where $WSS_i$ is the working-set size of process $i$, and $D$ is the total frame demand of all active processes.2 If $D > m$, where $m$ is the number of available physical frames, at least one process will be under-provisioned and thrashing becomes likely.2

Footnotes

1. Operating Systems: Virtual Memory - University course notes defining thrashing, its causes, and scheduler interaction. ↩ ↩² ↩³ ↩⁴

2. Thrashing - GeeksforGeeks - Explains locality, working set model, and page-fault frequency control. ↩ ↩² ↩³ ↩⁴ ↩⁵

3. What is Thrashing? Why Does it Occur? | Lenovo US - Describes practical symptoms and the role of excessive swapping. ↩

4. Peter J. Denning -- Working Set Publications - Primary historical source on working sets, locality, and thrashing prevention. ↩ ↩² ↩³ ↩⁴

5. THRASHING - Peter J. Denning - Classic overview of throughput collapse under excessive load and paging contention. ↩

What exactly is thrashing?

Thrashing is not merely “having many page faults.” It is the unstable condition in which the page-fault rate becomes so high that useful execution is overshadowed by paging overhead.2 The classic symptom is that the system becomes sluggish while storage activity remains intense.2 Historically, Peter Denning described it as a collapse of throughput caused by excessive contention for memory, especially when system load increases beyond a critical point.

This behavior is most common in systems using demand paging, because pages are brought into RAM only when referenced.2 Demand paging is efficient when a process's active pages fit in memory, but it becomes pathological when the active memory footprint of several processes no longer fits.2

Important indicators include:3

• Very high page-fault frequency
• Heavy disk or swap activity
• Poor response time
• Falling CPU utilization despite a high workload
• Throughput collapse as more processes are added

A concise distinction is shown below.

4

Footnotes

1. Operating Systems: Virtual Memory - University course notes defining thrashing, its causes, and scheduler interaction. ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶

2. THRASHING - Peter J. Denning - Classic overview of throughput collapse under excessive load and paging contention. ↩ ↩² ↩³

3. What is Thrashing? Why Does it Occur? | Lenovo US - Describes practical symptoms and the role of excessive swapping. ↩ ↩² ↩³

4. Peter J. Denning -- Working Set Publications - Primary historical source on working sets, locality, and thrashing prevention. ↩

5. Thrashing - GeeksforGeeks - Explains locality, working set model, and page-fault frequency control. ↩ ↩² ↩³

When does thrashing occur?

Thrashing occurs when the active memory demand of running processes exceeds available physical memory frames.3 More specifically, it arises when a process's current locality cannot be retained in memory long enough for reuse.2 In a multiprogrammed system, this often happens when the degree of multiprogramming becomes too high.2

Three common trigger conditions are especially important:

1. Insufficient frames for a process's current locality: if the pages needed in the near future are repeatedly evicted, the process faults on them again almost immediately.2
2. Too many concurrently active processes: the sum of working sets exceeds RAM, so the system cannot satisfy all active localities simultaneously.2
3. Aggressive global replacement effects: under global replacement, one memory-hungry process can steal frames from others, spreading instability system-wide.

The working-set test is the standard conceptual rule:

$$\text{If } \sum_i WSS_i > m,\text{ then thrashing is likely.}$$

Here, $WSS_i$ is the recent working set of process $i$, and $m$ is the total number of frames.2

Another useful control model is page-fault frequency (PFF). If the observed fault rate for a process rises above an acceptable upper bound, the process needs more frames; if no free frames exist, the system should reduce the active workload rather than continue admitting processes.2

Footnotes

1. Operating Systems: Virtual Memory - University course notes defining thrashing, its causes, and scheduler interaction. ↩ ↩² ↩³ ↩⁴

2. Thrashing - GeeksforGeeks - Explains locality, working set model, and page-fault frequency control. ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶

3. Peter J. Denning -- Working Set Publications - Primary historical source on working sets, locality, and thrashing prevention. ↩ ↩² ↩³ ↩⁴

4. THRASHING - Peter J. Denning - Classic overview of throughput collapse under excessive load and paging contention. ↩

5. Page Replacement Algorithms (UNC slides) - Describes page-fault frequency as a control method for allocating frames. ↩

Why does thrashing become self-reinforcing?

Thrashing is dangerous because it forms a feedback loop. When memory pressure grows, page faults increase; when page faults increase, the CPU waits more often for I/O; when CPU utilization falls, a simplistic scheduler may incorrectly assume the system can handle more work. Admitting more processes then reduces frames per process even further, which drives the page-fault rate still higher.2

This is why Denning's analysis is historically important: throughput does not always rise smoothly with load. Beyond a critical point, it can collapse suddenly. The paging device or backing store becomes the bottleneck, and the system enters a state sometimes described as “paging to death.”

A mathematical intuition is:

$$\text{Useful CPU fraction} \approx \frac{T_{\text{cpu}}}{T_{\text{cpu}} + T_{\text{paging}}}$$

As $T_{\text{paging}}$ grows large due to repeated page faults, the fraction of time spent on useful execution shrinks rapidly.2

Footnotes

1. Operating Systems: Virtual Memory - University course notes defining thrashing, its causes, and scheduler interaction. ↩ ↩² ↩³

2. THRASHING - Peter J. Denning - Classic overview of throughput collapse under excessive load and paging contention. ↩ ↩² ↩³ ↩⁴

How can thrashing be avoided?

Avoiding thrashing is fundamentally a problem of load control and frame allocation.2 The operating system must ensure that active processes have enough frames to cover their present locality.2 The principal strategies are below.

1. Use the working-set model

The working-set model estimates the set of pages each process has used within a recent window of references, often denoted by $\Delta$.2 The system keeps enough frames for that set, and if the sum of all working sets exceeds memory, it suspends or swaps out some processes rather than letting all of them run poorly.3

2. Use page-fault frequency control

PFF monitors the fault rate directly.2 If a process faults too often, the OS gives it more frames; if its fault rate is very low, some frames may be reclaimed.2 If free frames are unavailable, the correct response is often to reduce the number of active processes.2

3. Reduce the degree of multiprogramming

This is one of the most direct solutions.2 By suspending some processes, the system increases the memory available to the remaining ones, allowing their localities to fit and stabilizing execution.2

4. Prefer local replacement in unstable conditions

Local replacement prevents one process from stealing frames from others. While not a complete cure, it can contain the spread of thrashing.

5. Increase physical memory

Adding RAM increases the number of available frames and lowers the likelihood that active working sets exceed capacity.2 This is a practical remedy, though not the only one.

6. Design workload and admission policies carefully

Systems should avoid blindly increasing concurrency based only on CPU utilization. Better policies use memory pressure, fault rates, and working-set estimates before admitting more tasks.2

Footnotes

1. Operating Systems: Virtual Memory - University course notes defining thrashing, its causes, and scheduler interaction. ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸

2. Thrashing - GeeksforGeeks - Explains locality, working set model, and page-fault frequency control. ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹

3. Peter J. Denning -- Working Set Publications - Primary historical source on working sets, locality, and thrashing prevention. ↩ ↩² ↩³

4. THRASHING - Peter J. Denning - Classic overview of throughput collapse under excessive load and paging contention. ↩ ↩²

5. Page Replacement Algorithms (UNC slides) - Describes page-fault frequency as a control method for allocating frames. ↩ ↩² ↩³

6. What is Thrashing? Why Does it Occur? | Lenovo US - Describes practical symptoms and the role of excessive swapping. ↩

Practical summary

Thrashing is a memory-management failure state in which the system spends excessive time paging and too little time executing useful instructions.2 It occurs when active working sets do not fit in physical memory, commonly because the degree of multiprogramming is too high or frame allocation is insufficient.3 The most effective prevention methods are to monitor working sets or page-fault frequency, reduce active process load when necessary, and ensure that each active process has enough frames for its current locality.3

For exam and interview purposes, the essential rule is:

$$\text{Thrashing occurs when memory demand exceeds available frames for active localities.}$$

And the essential remedy is:

$$\text{Keep active working sets in RAM, even if that means running fewer processes at once.}$$

Footnotes

1. Operating Systems: Virtual Memory - University course notes defining thrashing, its causes, and scheduler interaction. ↩ ↩²

2. THRASHING - Peter J. Denning - Classic overview of throughput collapse under excessive load and paging contention. ↩

3. Thrashing - GeeksforGeeks - Explains locality, working set model, and page-fault frequency control. ↩ ↩²

4. Peter J. Denning -- Working Set Publications - Primary historical source on working sets, locality, and thrashing prevention. ↩ ↩²

5. Page Replacement Algorithms (UNC slides) - Describes page-fault frequency as a control method for allocating frames. ↩