page-fault frequency

Thrashing has a single, directly measurable symptom: a process is faulting too often. The page-fault-frequency approach skips trying to model exactly which pages a process needs and instead just watches the fever thermometer — the rate at which the process generates page faults — and gives it more or fewer frames to keep that rate inside a healthy band. It treats the fault rate itself as the control signal.

Here is the mechanism. The OS sets an upper and a lower threshold on each process's page-fault rate. If a process's fault rate climbs above the upper threshold, it is starved for frames — about to thrash — so the OS gives it more frames. If its fault rate falls below the lower threshold, it has more frames than it needs, so the OS can safely take some away to give to others. The process is left alone while its rate stays between the two thresholds. So instead of computing a working set, PFF directly tunes each process's frame allotment by feedback, the way a thermostat adds or removes heat to keep a room in range. If demand exceeds total memory even after this — every process is above its upper threshold and there are no free frames left — the OS must suspend a process entirely, freeing its frames for the rest.

Why it matters: PFF is a simpler, more direct anti-thrashing control than maintaining working-set windows, because the fault rate is cheap to measure and is exactly the quantity we care about. It is closely related to the working-set model — both aim to give each process enough frames for its current locality — but PFF reacts to the observed symptom rather than estimating the cause. The honest limit: thresholds must be tuned, and PFF reacts after faults have already started rising, so it controls thrashing rather than perfectly preventing it.