MGLRU-FG speeds up Linux memory reclamation by up to 40% in early tests
Kairui Song’s MGLRU-FG patches add frequency-guided promotion to Linux’s Multi-Gen LRU and deliver 10–40% gains depending on workload, peaking at 76% under zRAM. The series is still RFC, but the results on MongoDB, Chromium and kernel builds make it worth tracking closely.
December 2022. The Multi-Gen LRU (MGLRU) lands in Linux 6.1 and changes how the kernel reclaims memory pages under pressure, with measurable wins on servers and Android alike. 3 October 2026. Developer Kairui Song posts the third revision of his MGLRU-FG patches, a “frequency-guided promotion” layered on top of the existing eviction logic. 4 October 2026. Phoronix reports the first numbers: 10–40% more performance depending on the workload, peaking at 76% on a Chromium and Node.js test under zRAM. Why it matters: memory reclaim is one of the few kernel knobs that benefits every process on a box without adding hardware, and a double-digit gain translates straight into latency — and eventually cloud spend — across a whole fleet.
What MGLRU already fixed
Before MGLRU, Linux page reclaim leaned on two lists — Active and Inactive — and a binary heuristic: a recently touched page is “active”, an untouched one is “inactive” and eventually gets evicted. That model holds as long as a process’s working set fits in memory. The moment it overflows, hot and cold pages mix in the same lists, the kernel evicts pages that are still in use, and the box starts to thrash: refaults spike and latency collapses.
MGLRU, proposed by Yu Zhao and merged in Linux 6.1, replaces the two-list pair with a ladder of generations. A promoted or freshly accessed page climbs toward the young generations; a forgotten page sinks toward the old ones; eviction targets the oldest first. The result is an eviction decision that tracks the real working set, with gains already documented under memory pressure on servers, desktops and mobile devices.
That outcome is rare in scope. The Active/Inactive pair is one of the oldest mechanisms in the kernel, and it had almost never been questioned in depth before MGLRU. The generation ladder ranks pages not by a binary presence in a list but by a trajectory: a hotly accessed page stays young, a forgotten page ages gradually. Eviction becomes a gradual decision instead of a hard flip, which lowers the odds of throwing out the wrong page at the exact moment a process needs it.
Proactive promotion instead of reactive eviction
MGLRU-FG pushes the idea one step further. Until now, MGLRU protected its tiers at eviction time through a PID controller that tunes how quickly pages drift down the generations. Kairui Song adds frequency-guided promotion: instead of waiting until a page is about to be evicted before deciding whether it deserves to stay, the kernel promotes it proactively as soon as its access counter crosses a threshold.
The mechanism rides on a reference counter stored in folio flags. Every access increments the counter, which still maps to logarithmic tiers, but with formalized thresholds: LRU_REFS_REFERENCED (1), LRU_REFS_WORKINGSET (2), LRU_REFS_PROTECTED (3) and LRU_REFS_MAX (7). Once the counter reaches a threshold, the folio is promoted without waiting for the controller to kick in. PG_workingset and PG_referenced become the two low bits of that counter, with the high bits supplied by LRU_REFS_MASK. The side effect is a win on its own: the kernel saves one bit of page flags — valuable on architectures where those bits are scarce — while making reference accounting more accurate.
The numbers, workload by workload
This is the part an operator cares about. The measurements reported by Phoronix span several architectures, servers, desktops and Android, and Song sums it up as “10%–40% higher performance or lower refault in various different tests”.
The per-workload detail is telling. The kernel build gains about one second, and close to ten seconds when run with 96 jobs to raise memory pressure. MongoDB improves by 13.5%. The Chromium and Node.js test that relies on zRAM as swap shows a 76% improvement. FIO sees throughput rise by up to 11%. The numbers are deliberately uneven — and that is the point: the gain is largest exactly where reclaim is the bottleneck, i.e. on workloads that overflow physical memory or depend on compressed swap.
The breadth of platforms matters too. Song stresses that the results reproduce “across multiple servers of different archs, desktops, and Android”. This is not a single flattering benchmark, but a consistent trend measured on heterogeneous targets — which strengthens the credibility of a patch this central.
Why it is still an RFC
Song keeps the RFC (request for comments) status, and it is a deliberate call. The patch rewrites the LRU in depth, including the way Active/Inactive indicators are read, which makes it a high-risk change to infrastructure this central. He notes himself that V3 is “more affected by anon over-reclaim” but delivers better overall results, a problem “to fix later or separately”. In other words: the code is “already very usable, stable and performing well”, but nobody has yet audited it for a mainline merge.
Practically, that means MGLRU-FG is not in Linux 7.3 — whose rc6 just shipped — and it will not arrive through a routine distribution update in the coming weeks. The path runs through the linux-kernel mailing list (LKML), maintainer feedback, and an eventual later merge window.
What it changes for an operator
Nothing to install today, but three things to watch. First, if you run reclaim-sensitive workloads — databases, build servers, tightly packed containers, zRAM-backed desktops — these numbers measure exactly the opportunity cost you are paying right now. Second, the one-bit page flags saving matters to embedded kernels and architectures where flag bits are scarce, not just to big servers. Third, the RFC status is an invitation to test: maintainers need reports on real workloads before a merge is on the table.
There is a quieter audience that stands to gain just as much: mobile and embedded Linux. Android is explicitly named among the tested targets, and for phones and single-board devices the combination of limited RAM and zRAM-backed swap makes reclaim quality directly visible in app-switch latency and battery life. The one-bit page flags saving is the same story at the low end — every flag bit is scarce on embedded SoCs, so a change that speeds up reclaim while also freeing a bit is unusually valuable where RAM and flags are both tight.
Verdict
If you operate memory-bound workloads — heavy builds, MongoDB, or zRAM endpoints — file the topic and follow Kairui Song’s LKML thread: this is the kind of patch whose payoff lands without changing a single line of your configuration. If your fleet runs stable distribution kernels, do nothing for now — the patch is unmerged, and the risk of a change this deep does not belong in production before maintainers sign off. If you test development kernels or contribute, your report on real workloads is exactly what is missing to turn a promising RFC into a mainline feature. The direction is clear: Linux reclaim is moving from reactive eviction to proactive promotion, and MGLRU-FG is the most quantified proof of it yet. For maintainers, the open question is whether frequency-guided tiering can be folded into MGLRU without regressing the workloads that already benefit from it — that is exactly what the RFC cycle exists to settle.