Thrashing

Introduction

Have you ever experienced your computer becoming painfully slow — the hard disk light blinking constantly, applications frozen, mouse barely moving? You might have been experiencing thrashing. It happens when your system spends more time moving pages between RAM and disk than actually executing programs. The computer is busy doing work, but none of that work is productive.

Thrashing occurs when a process does not have enough frames (physical memory pages) to hold its actively used pages. It constantly page faults — loading one page causes another needed page to be evicted, which is immediately needed again, causing another fault, in an endless cycle. The system degenerates into a disk-bound state where the CPU sits idle waiting for page I/O.

How Thrashing Happens

The deadly cycle:

1. OS observes CPU utilization is low (processes are blocked on page faults)
2. OS increases degree of multiprogramming (admits more processes)
3. More processes = less memory per process = more page faults
4. More page faults = CPU even more idle (waiting for disk)
5. OS sees low CPU → admits EVEN MORE processes
6. System collapses into thrashing — nearly 0% productive CPU use

The Working Set Model

The working set of a process is the set of pages it is actively using during a time window. If the OS can keep each process's working set in memory, page faults will be rare and the system runs smoothly.

Using Working Sets to Prevent Thrashing

Rule: Total working set sizes of all processes must not exceed available frames.

Page Fault Frequency (PFF) Strategy

A more practical approach: monitor each process's page fault rate directly.

• If fault rate is too HIGH → process needs more frames (allocate more)
• If fault rate is too LOW → process has excess frames (take some away)
• Set upper and lower bounds on acceptable fault rate

Causes of Thrashing

1. Too many processes: Total memory demand exceeds physical RAM
2. Insufficient frames per process: Even with few processes, poor allocation
3. Poor locality: Programs with scattered access patterns need more frames
4. Memory leaks: Programs gradually consume more memory until RAM is exhausted

Preventing Thrashing

1. Working Set Strategy

Track each process's working set and ensure total working sets fit in RAM. If they do not, suspend processes until they do.

2. Page Fault Frequency

Monitor fault rates and dynamically adjust frame allocation per process.

3. Swapping

When thrashing is detected, swap entire processes out to disk to free memory for remaining processes.

4. Adding RAM

The ultimate solution — more physical memory means larger working sets fit without swapping.

5. Load Control

Limit the degree of multiprogramming (number of active processes) based on available memory.

Detecting Thrashing

Signs of thrashing:

• High page fault rate across multiple processes
• Disk I/O at 100% while CPU utilization is low (< 20%)
• System response time increases dramatically
• Little productive work despite high system activity

Real-World Analogy

Thrashing is like a student trying to study 10 subjects simultaneously with only one textbook open at a time. They read one page of Math, then need Physics, so they close Math and open Physics. Then they need Chemistry, so they close Physics and open Chemistry. They spend all their time opening and closing books (page faults) and never actually read anything (no productive CPU work). The solution: focus on fewer subjects at a time (reduce multiprogramming) so each subject gets enough continuous attention (pages in memory).

Key Takeaways

• Thrashing occurs when processes spend more time paging than executing
• It creates a death spiral: low CPU → more processes → more faults → lower CPU
• The working set model defines the minimum frames a process needs for efficient execution
• Total working set sizes must fit in available RAM to avoid thrashing
• Page Fault Frequency monitoring provides a practical approach to detecting and preventing thrashing
• Solutions include reducing multiprogramming, swapping out processes, and adding physical RAM
• Thrashing is why simply adding more processes does not always improve performance