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

Wei Gao wegao@suse.com
Tue Sep 1 04:04:33 CEST 2026


On Thu, Aug 27, 2026 at 04:21:50PM +0200, Cyril Hrubis wrote:
> Hi!
> > yes, basically we re-implement some sort of OOM-killer/memory.reclaim
> > inside the code, instead of using them directly. That means we need to
> > disable OOM killer, loop over the current swap status and eventually
> > raise an error if after N iterations pages are not swapped.
> > 
> > But I feel it's not deterministic because on a really slow device we
> > might run out of iterations. I still think memory.reclaim is the best
> > choice for v2 in this case, because it will wait until a certain amount
> > of memory has been reclaimed and eventually raise an error.
> > 
> > @Cyril do you have any idea on how to proceed here?	
> 
> If the goal is to make sure that kernel swaps when memory.max is reached
> we may as well slow down the dirtying loop so that it dirties memory
> with speed 20MB/s when it gets close to the limit.
> 
> Something as:
> 
> diff --git a/testcases/kernel/mem/mmapstress/mmapstress06.c b/testcases/kernel/mem/mmapstress/mmapstress06.c
> index 4e6023399..2c0c6fb02 100644
> --- a/testcases/kernel/mem/mmapstress/mmapstress06.c
> +++ b/testcases/kernel/mem/mmapstress/mmapstress06.c
> @@ -59,8 +59,9 @@ static void run_test(void)
>  
>                 for (size_t i = 0; i < map_size; i += page_size) {
>                         mmapaddr[i] = 'a';
> -                       if ((i % (2 * 1024 * 1024)) == 0)
> -                               usleep(1000);
> +
> +                       if (i >= mem_limit && !(i % (2 * 1024 * 1024)))
> +                               usleep(100000);
>                 }
> 
> The testrun increses to 6s from 1s but it makes the OOM very unlikely to
> happen.
Thanks for your suggestion.
I have tested above solution in our openqa setup but still encounter failure, 3 test cases
still failure with oom after run 100 cases. Maybe slow down dirty loop
is still too late?

> 
> -- 
> Cyril Hrubis
> chrubis@suse.cz


More information about the ltp mailing list