What is thrashing and how does an OS deal with it?

Compare the memory the active processes need right now with the RAM available.

Model answer. Thrashing is the state in which the system spends most of its time moving pages between RAM and disk instead of executing useful instructions. Page faults become so frequent that processes are almost always waiting on the paging device.

Cause

• Each process has a working set: the pages it actively uses over a recent window of time (its current locality).
• If the sum of the working sets of all running processes exceeds physical memory, a process that faults must evict a page another process is about to need. That process then faults too, and so on.
• A classic feedback loop makes it worse: CPU utilisation drops because everyone is waiting for I/O, a naive long-term scheduler sees an idle CPU and admits more processes, which shrinks everyone's share of memory further.

Symptoms / detection

• Very high page-fault rate and heavy swap or disk activity.
• Low CPU utilisation in user mode despite many runnable processes.
• The system feels frozen; on Linux tools such as vmstat show large swap-in/swap-out (si/so) values.

Remedies

• Reduce the degree of multiprogramming: suspend or swap out whole processes so the remaining ones fit.
• Working-set model: keep each process's working set resident and only run a process if its working set fits.
• Page-fault frequency (PFF) control: if a process faults too often, give it more frames; if it rarely faults, take frames away; if no frames are free, suspend a process.
• Local replacement policies stop one process from stealing frames from others (limits the spread, does not cure it).
• Practical fixes: add RAM, fix memory-hungry code, improve locality.

Common follow-up: "Will a better page-replacement algorithm fix thrashing?" Only marginally. If the combined working sets do not fit in memory, every algorithm will fault constantly; the real fix is reducing demand or adding memory.