Re: mm: pages are not freed from lru_add_pvecs after process termination

[Michal Hocko <mhocko@kernel.org>]

On Tue 07-06-16 09:02:02, Odzioba, Lukasz wrote:
[...]
> //compile with: gcc bench.c -o bench_2M -fopenmp
> //compile with: gcc -D SMALL_PAGES bench.c -o bench_4K -fopenmp
> #include <stdio.h>
> #include <sys/mman.h>
> #include <omp.h>
> 
> #define MAP_HUGE_SHIFT  26
> #define MAP_HUGE_2MB    (21 << MAP_HUGE_SHIFT)
> 
> #ifndef SMALL_PAGES
> #define PAGE_SIZE (1024*1024*2)
> #define MAP_PARAM (MAP_HUGE_2MB)

Isn't MAP_HUGE_2MB ignored for !hugetlb pages?

> #else
> #define PAGE_SIZE (1024*4)
> #define MAP_PARAM (0)
> #endif
> 
> void main() {
>         size_t size = ((60 * 1000 * 1000) / 288) * 1000; // 60GBs of memory 288 CPUs
>         #pragma omp parallel
>         {
>         unsigned int k;
>         for (k = 0; k < 10; k++) {
>                 void *p = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANON | MAP_PARAM, -1, 0);

I guess you want something like posix_memalign or start faulting in from
an aligned address to guarantee you will fault 2MB pages. Also note that
the default behavior for THP during the fault has changed recently (see
444eb2a449ef ("mm: thp: set THP defrag by default to madvise and add a
stall-free defrag option") so you might need MADV_HUGEPAGE.

Besides that I am really suspicious that this will be measurable at all.
I would just go and spin a patch assuming you are still able to trigger
OOM with the vanilla kernel. The bug fix is more important...
-- 
Michal Hocko
SUSE Labs