[LTP] [PATCH v2 1/3] hugemmap10: Account for memory policy in mmap counter checks

Li Wang li.wang@linux.dev
Thu Oct 8 10:26:39 CEST 2026


Huaisheng Ye wrote:

> Expected surplus accounting for mappings that reserve at mmap() time only
> considers the global free and reserved hugepage counters. But sometimes,
> for instance with MPOL_BIND, globally free hugepages can reside outside
> nodes from which the task can allocate or plans to allocate. Hugetlb
> then creates surplus pages on allowed nodes, while the test expects
> no counter change.
> 
> For example, reproduce this on an eight-node system running 7.3.0-rc1:
> 
>     $ numactl --membind=0-3 ./hugemmap10
>     tst_hugepage.c:84: TINFO: 3 hugepage(s) reserved
>     ...
>     hugemmap10.c:386: TINFO: Base pool size: 0
>     hugemmap10.c:313: TINFO: Clean...
>     hugemmap10.c:364: TINFO: OK
>     hugemmap10.c:313: TINFO: Untouched, shared...
>     hugemmap10.c:364: TINFO: OK
>     hugemmap10.c:313: TINFO: Untouched, private...
>     hugemmap10.c:364: TINFO: OK
>     hugemmap10.c:313: TINFO: Touched, shared...
>     hugemmap10.c:364: TINFO: OK
>     hugemmap10.c:313: TINFO: Touched, private...
>     hugemmap10.c:364: TINFO: OK
>     hugemmap10.c:386: TINFO: Base pool size: 1
>     hugemmap10.c:313: TINFO: Clean...
>     hugemmap10.c:319: TFAIL: While doing mmap shared with no touch: Bad HugePages_Total: expected 1, actual 2
>     hugemmap10.c:319: TFAIL: While doing mmap shared with no touch: Bad HugePages_Free: expected 1, actual 2
>     hugemmap10.c:319: TFAIL: While doing mmap shared with no touch: Bad HugePages_Surp: expected 0, actual 1
> 
>     Summary:
>     passed   0
>     failed   3
>     broken   0
>     skipped  0
>     warnings 0
> 
>     $ numactl --membind=4-7 ./hugemmap10
>     ...
>     hugemmap10.c:364: TINFO: OK
>     hugemmap10.c:429: TPASS: Hugepages Counters works as expected.
> 
>     Summary:
>     passed   1
>     failed   0
>     broken   0
>     skipped  0
>     warnings 0
> 
> If global free hugepages are on nodes 4-7 while the memory policy restricts
> hugemmap10 to nodes 0-3, the counter discrepancy is observed.
> 
> Read the task policy and cpuset mask, then sum free hugepages on the
> nodes available to the mapping. Calculate the expected surplus as the
> maximum of the global and allowed-node shortfalls. Match hugetlb's fallback
> to the cpuset when an MPOL_BIND mask no longer intersects it.
> 
> This fixes counter expectations for MAP_SHARED and MAP_PRIVATE mappings
> that create reservations at mmap() time.
> 
> This complements the hugetlb reservation fix:
> https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git/commit/?h=mm-new&id=506f9bf248c092fc80df046f9deb26094ea84592
> 
> Signed-off-by: Huaisheng Ye <yehuaisheng@open-hieco.net>

Reviewed-by: Li Wang <li.wang@linux.dev>

-- 
Regards,
Li Wang


More information about the ltp mailing list