Re: [PATCH v2 00/12] mm/mglru: improve reclaim loop and dirty folio handling

Leno Hou
2026-04-01T05:18:37Z

On 3/29/26 3:52 AM, Kairui Song via B4 Relay wrote:
> The aging OOM is a bit tricky, a specific reproducer can be used to
> simulate what we encountered in production environment [4]: Spawns
> multiple workers that keep reading the given file using mmap, and pauses
> for 120ms after one file read batch. It also spawns another set of
> workers that keep allocating and freeing a given size of anonymous memory.
> The total memory size exceeds the memory limit (eg. 44G anon + 8G file,
> which is 52G vs 48G memcg limit).
>
> - MGLRU disabled:
> Finished 128 iterations.
>
> - MGLRU enabled:
> OOM with following info after about ~10-20 iterations:
> [ 154.365634] file_anon_mix_p invoked oom-killer: gfp_mask=0xcc0(GFP_KERNEL), order=0, oom_score_adj=0
> [ 154.366456] memory: usage 50331648kB, limit 50331648kB, failcnt 354207
> [ 154.378941] swap: usage 0kB, limit 9007199254740988kB, failcnt 0
> [ 154.379408] Memory cgroup stats for /demo:
> [ 154.379544] anon 44352327680
> [ 154.380079] file 7187271680
>
> OOM occurs despite there being still evictable file folios.
>
> - MGLRU enabled after this series:
> Finished 128 iterations.

Hi Kairui,

I've tested on v6.1.163 and unable to reproduce the OOM issue by your
test script [4], Could you point the kernel version in your environment
or more information?

Link:
https://github.com/ryncsn/emm-test-project/tree/master/file-anon-mix-pressure
[4]

--
Best Regards,
Leno Hou