[LTP] [PATCH v1] mmapstress06: Rate limit page-dirtying loop to prevent MemCG OOM-kills

[Wei Gao]

On Wed, Aug 26, 2026 at 07:58:34AM +0000, Andrea Cervesato wrote:
> Hi Wei,
> 
> > The goal of this test is to reach memory.max and trigger kernel-driven 
> > swapping as a direct result of hitting that limit.
> > Proactively calling memory.reclaim forces swapping before reaching memory.max, 
> > meaning the memory limit is never actually reached. Furthermore, if calling memory.reclaim 
> > after hitting memory.max is too late to prevent OOM-kills on slow storage.
> > So i do not think `memory.reclaim` solution can help on our oom failure.
> 
> memory.reclaim doesn't run during the pressure, but right after we
> reached the memory limit, so OOM killer can be handled by excluding
> it from the chain and getting an error instead of an OOM kill. In this
> way we know if there's an error while swapping, instead of guessing that
> device is too slow.
> 
> That's basically what we would do if we want to implement something
> that is suitable for all the devices: we disable OOM killer in the cgroup,
> we remove any sleep, we give a max runtime and if that is reached, it
> means that after a number of attempts we are still not swapping -> TFAIL.
> 
> Just notice that what I just described is not so far from what OOM-killer
> or memory.reclaim does. The ending result is exactly the same, but we
> do things by hand.
> 
Thanks for the technical discussion, and we should find better solution
for avoid oom, but on cgroupv2(does not support disabling the OOM killer)
scenario, replacing sleep-based pacing with memory.reclaim is simply replacing 
one guess with another. In user-space, it is impossible to catch the exact 
second when memory hits memory.max. Furthermore, calling memory.reclaim proactively 
just guesses when to bypass memory.max altogether, which invalidates the 
core goal of the test.

> --
> Andrea Cervesato
> SUSE QE Automation Engineer Linux
> andrea.cervesato@suse.com