Thrashing and Working Set Model

When the System Spends More Time Swapping Than Actually Working

Thrashing happens when the CPU spends so much time swapping pages in and out of memory (paging, covered earlier in this section) that very little time is left for processes to actually make real progress - a system can appear to be extremely busy while accomplishing almost nothing useful.

Normal operation:  [ useful work ][ occasional page swap ][ useful work ]

Thrashing:  [swap][swap][tiny work][swap][swap][swap][tiny work][swap]...
            (most of the time is spent swapping, very little on actual useful execution)

How a System Gradually Slides Into Thrashing

As more processes are added and each one is allocated fewer physical frames, each process has less of its actively-needed memory available at once - triggering more frequent page faults (needing to fetch missing pages), which triggers more swapping, which leaves even less actual CPU time for genuine execution, further worsening the underlying problem.

The Working Set Model: A Way to Prevent It

The working set model tracks the specific set of pages a process has actually referenced recently - its "working set" - and ensures a process is only run if enough physical frames are available to hold its entire current working set.

Process's working set (pages referenced in the recent time window): {2, 5, 7, 9}

If fewer than 4 frames are currently available for this process,
don't schedule it yet - doing so would almost certainly trigger thrashing.

Why Enforcing This Directly Prevents the Problem

By refusing to run a process unless its actual working set genuinely fits in available memory, the system avoids the exact repeated page-fault cycle that causes thrashing in the first place - trading some processes waiting longer to start, in exchange for the ones that do run actually making real, efficient progress.

Why Understanding Thrashing Matters for Real Systems

A system exhibiting high disk activity alongside surprisingly low actual CPU utilization on useful work is a classic, recognizable symptom of thrashing - understanding this concept directly helps diagnose exactly why a system that "should" have plenty of resources can still feel completely unresponsive under the wrong workload.