The full picture
- Why not true LRU: perfect recency ordering means bookkeeping on every memory access — hardware gives you only a referenced bit per page; clock/second-chance is 'LRU with one bit of memory', and it's within a few percent of LRU on real workloads.
- Belady's insights worth citing: the optimal algorithm (evict the page used furthest in the future) is unimplementable but benchmarkable; and FIFO can get worse with more memory (Belady's anomaly) — why stack-property algorithms like LRU matter.
- Thrashing signatures: high majfl + high disk I/O + low user CPU + load average climbing — 'busy but nothing finishes'. Modern Linux adds PSI (pressure stall information,
/proc/pressure/memory) as the direct 'time stalled on memory' metric — alert on it. - The cloud translation: in containers there's often no swap, so 'thrashing' appears as page-cache evict/reload storms (files re-read constantly) or as the OOM killer — same disease, different symptom. Working-set thinking survives: it's what K8s memory requests are supposed to be.