[LTP] [PATCH] hugemmap10: Account for memory policy in counter checks

[Huaisheng Ye]

On 9/16/2026 17:37, Li Wang wrote:
>> Aside from this patch, my test encountered new failures on a four-node system.
>> Without your patch, the surplus failure can be reproduced consistently, so I
>> suspect it's a different issue.
>>
>> ...
>> hugemmap10.c:402: TFAIL: While doing munmap shared after touch: Bad HugePages_Total: expected 1, actual 2
>> hugemmap10.c:402: TFAIL: While doing munmap shared after touch: Bad HugePages_Free: expected 1, actual 2
>> hugemmap10.c:402: TFAIL: While doing munmap shared after touch: Bad HugePages_Surp: expected 0, actual 1
> The test system has four nodes, and only nodes 0 and 2 have memory.
> I guess that's what caused the failure when running hugemmap10 during
> hugepage allocation.
>
> Something like this:
>
> 1. The test pre-allocates 1 hugepage, which defaults to Node 0.
>
> 2. When the test runs on Node 2, the kernel dynamically creates a surplus
>     hugepage on Node 2 to ensure local memory performance.
>
> 3. The global hugepage count becomes 2 (1 on Node 0 + 1 surplus on Node 2).
>
> 4. The test expects exactly 1 global hugepage, so it reports a failure.
>
> Below are the test results from patched-hugemmap10 on patched-kernel-6.6.
> I'll do more investigation tomorrow.

Yes, I can reproduce it with stable kernel v6.6.145. However, after backporting
commit d0f14f7ee0e2 ("hugetlb: prioritize surplus allocation from current node"),
the issue is resolved.

Commit d0f14f7ee0e2 was designed to fix the side effect of commit 003af997c8a9,
which had been backported to v6.6 stable to ensure that surplus huge pages come
from mempolicy-allowed nodes.

So you could try v6.6 stable with d0f14f7ee0e2 applied, or upstream v7.3-rc.

Kind Regards,
Huaisheng Ye