Linux 7.3 includes Baolin Wang’s change to give mapped executable file folios better protection in MGLRU after first use. The reported benefit comes from a memory-constrained kernel build. It does not mean executable code can never be evicted.
The reference-tracking problem
The patch explains that earlier scanning could clear access information before reclaim evaluated it. First use of mapped executable file folios could then receive insufficient protection. The change promotes them in MGLRU's reference-handling paths, following the intent of classical LRU.
This improves their chance of remaining resident; it does not pin all program code indefinitely. Memory reclamation must still choose what to keep under pressure. An executable mapping alone also does not prove every page will immediately be used again.
What the published numbers measure
Wang reports a 32-core Arm machine, a memory-cgroup limit of 2G and a kernel build with 32 parallel jobs. The patch gives these system CPU time values:
| Version | Reported system CPU time |
|---|---|
| Baseline | 9248.543 seconds |
| Patched | 7861.579 seconds |
The reduction is 1386.964 seconds, approximately 15.0% of the baseline. Those are the contributor's measurements, not results reproduced by PeopleAreGeek.
System CPU time can accumulate across concurrent workers. It is different from the wall-clock duration between starting and finishing the build. For example, four workers each spending one simultaneous second in kernel execution contribute four CPU seconds during one elapsed second. That example illustrates accounting, not this benchmark's actual timeline.
The two reported values alone therefore do not establish a 15% faster completed build, a general 15% application speedup or an energy saving.
Check whether MGLRU is active before comparing
The kernel administration guide documents the runtime bitmask. Read it without changing the setting:
cat /sys/kernel/mm/lru_gen/enabledBit 0, written as 0x0001, is the main enable switch. The file can be absent when the kernel does not expose the feature. A distribution can also backport a change, so a version label is not the only evidence of the code in use.
For your own comparison, keep source tree, compiler, job count, memory limit and storage constant. Record elapsed, user and system time separately, together with memory pressure and I/O. Repeat runs and state cache conditions. That record can show whether better code retention helps your workload, without turning one deliberately constrained build into a universal prediction.
Use the exact patch benchmark and distinguish aggregate system CPU time from elapsed build time; remove guarantees that executable pages cannot be reclaimed.