thrashing

Imagine trying to study at a desk so tiny it holds only one book, while you actually need to flip between five. Every time you reach for a different book you must shelve the one you have and fetch another — and the moment you do, you need the one you just shelved. You spend all your time walking to and from the shelf and almost no time reading. A computer in exactly this state is thrashing: it spends nearly all its effort moving pages between memory and disk and gets almost no real work done.

Concretely, thrashing happens when processes have too few frames to hold their working set — the pages they actively need right now. With too little memory each process faults constantly: it brings in a needed page by evicting another page it will need a moment later, so it immediately faults again. This sets off a vicious spiral. The CPU sits idle waiting for slow disk I/O, so utilization drops; a scheduler that watches low CPU utilization concludes it should admit MORE processes to keep the CPU busy; the new processes need frames too, so every process now has even fewer frames, faults even harder, and CPU utilization collapses further. Past a tipping point, adding load makes throughput plummet rather than rise.

Why it matters and a common misconception: thrashing is not 'the disk being slow' or 'a bug' — it is a global behaviour that emerges when memory is over-committed relative to the active demand. The cure is to control the degree of multiprogramming so each process keeps enough frames for its working set: the working-set model tracks how many frames each process actually needs and suspends processes if the total exceeds available memory; the page-fault-frequency (PFF) scheme watches each process's fault rate and gives it more frames if it faults too often or takes frames away if it faults rarely. Note that locality of reference is what makes this fixable at all — programs cluster their references, so a modest, well-chosen frame allotment usually suffices.