MGLRU reclaim rewritten so swappiness finally means what it says

Multi-Gen LRU, the kernel's newer page reclaim design, has long treated the swappiness knob as a weak hint. Classic LRU uses that setting to decide how much anonymous memory versus file cache to scan. MGLRU picked one type, then let fallback logic override the bias. Changing swappiness from 1 to 200 therefore moved far less work than administrators expected.

Barry Song of Xiaomi has posted a ninth revision of a series that replaces that model. The core, from Kairui Song of Tencent, computes how many anonymous and file pages to scan on each reclaim pass from recent refault rates, the same idea classic LRU uses, instead of choosing a single type and hoping fallbacks honor the setting. The series also lets reclaim touch the two youngest generations, including the youngest itself, when memory pressure rises.

That last point is the practical failure. Under heavy pressure, aging could not keep up with reclaim. Threads aborted because they saw empty generations or only the minimum number left, and the machine hit out-of-memory while classic LRU did not. An earlier fix, already merged, reduced the problem. Song writes that Song could still reproduce the kill after hundreds of iterations before this series, and that it no longer occurs with the new patches applied.

Song also fixes a cold/hot inversion that the wider scan made worse, and that already existed in mainline. Rejected pages were put back where they would be scanned again immediately. On one file workload, reclaim efficiency rose from about 6 percent of scanned pages stolen to about 64 percent. Building a kernel at swappiness 1 dropped from roughly four and a half minutes of system time to under four.

Gaofei Lyu and Song add aging when folio generations are badly unbalanced, and a small file-scan share even at swappiness 200. That extreme had left the file factor at zero and, on some machines, made workloads about three times slower under MGLRU than under classic LRU. Bo Zhang separately fixes a GFP_NOIO problem in the same path. After the series, stolen file pages track classic LRU across the swappiness range: heavy file reclaim at low values, heavy anonymous reclaim at high ones.