[LTP] [PATCH] mmap_24-1: Change vm.max_map_count if needed

[Li Wang]

Martin Doucha <mdoucha@suse.cz> wrote:

> On 09. 05. 25 6:03, Li Wang wrote:
> > There aremany ways toavoid OOM (e.g., overcommit_memory, oom_score_adj,
> > ulimit, etc.). However, the purpose of the mmap_24-1.c test is to
> > exhaust thevirtual
> > address space and trigger ENOMEM.
> >
> > Limiting vm.max_map_count may prevent OOM, but it changes the failure
> > cause to
> > hitting themap count limit, not actual address space exhaustion, which
> > might be away
> > from thetest's intent.
> >
> > Iguess using setrlimit(RLIMIT_AS, ...) is more appropriate here, as it
> > enforces address
> > space limits while preserving the original test goal.
>
> 64bit address space is so large that exhausting it requires 512+GB of
> page table structures alone (for the 48bit variant). And kernel will not
> return ENOMEM when it runs out of free memory for pagetable structures,
> it'll trigger OOM.

Indeed.

>
> The mmap_24-1 test started failing after the default vm.max_map_count
> increased in one of our tested product so this is the limit we want to

That suggests the issue is actually due to the process reaching the
vm.max_map_count limit, which results in ENOMEM errors in your
regularly tested product.

Give the fact, I agree with you patch, it addresses the root cause effectively.
But I recommend updating the code comments to reflect that the failure
comes from exceeding the maximum number of memory mappings,
not overall memory exhaustion.


> change here. But you could copy the test and change RLIMIT_AS there.
> That would also be a valid test case.
>
> --
> Martin Doucha   mdoucha@suse.cz
> SW Quality Engineer
> SUSE LINUX, s.r.o.
> CORSO IIa
> Krizikova 148/34
> 186 00 Prague 8
> Czech Republic
>


-- 
Regards,
Li Wang