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

[Wei Gao]

On Tue, Aug 25, 2026 at 12:16:08PM +0000, Andrea Cervesato wrote:
> Hi Wei,
> 
> > Reduce the throttling interval from 2 MB to 64 KB (usleep for 200us
> > every 64 KB) in the page-dirtying loop. This smooths out allocation
> > spikes and gives asynchronous swap writeback time to catch up under
> > slower VM storage environments, avoiding unexpected MemCG OOM-kills.
> 
> Unfortunately this is not a solution but a workaround, we need to make
> sure that we are able to see any change to the swap memory while
> allocating dirty pages close to the memory.max. This is probably a
> fix for a specific target rather than complete fix.
> 
> We need to find an another way to ensure that OOM killer won't kick in.
> That is caused by the time between releasing swap and storing swapped
> data inside the hard disk. If that is not gonna happen for a certain
> amount of times, the OOM killer kicks. By reducing the throttling
> interval, we simply pause more time over 256MB of memory, but an even
> slower machine won't fit into these intervals of 64KB.
> 
> There's not a "clean" solution, but we can use the v2 cgroup support
> for `memory.reclaim` and request enough data while we are swapping it.
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.

> 
> On v1 we can either disable the cgroup OOM killer via memory.oom_control
> so the child blocks instead of being killed, or keep the loop unthrottled
> (the kernel already blocks faults in direct reclaim at memory.max) and
> report an OOM kill as TBROK via the child's exit status.
> 
> Regards,
> --
> Andrea Cervesato
> SUSE QE Automation Engineer Linux
> andrea.cervesato@suse.com