Re: [PATCH v2 00/12] mm/mglru: improve reclaim loop and dirty folio handling
From: Leno Hou
Date: Wed Apr 01 2026 - 01:19:08 EST
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