From: Li Wang <li.wang@linux.dev>
To: Huaisheng Ye <yehuaisheng@open-hieco.net>,
tsahu@linux.ibm.com, pvorel@suse.cz, ltp@lists.linux.it
Subject: Re: [LTP] [PATCH] hugemmap10: Account for memory policy in counter checks
Date: Wed, 16 Sep 2026 17:37:42 +0800 [thread overview]
Message-ID: <aqpjZsOCq-jDfks_@linux.dev> (raw)
In-Reply-To: <aqpX1P1bNIEol4yt@linux.dev>
>
> 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.
[root@SL26GA ~]# numactl -H
available: 4 nodes (0-3)
node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79
node 0 size: 31729 MB
node 0 free: 30582 MB
node 1 cpus: 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95
node 1 size: 0 MB
node 1 free: 0 MB
node 2 cpus: 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111
node 2 size: 31896 MB
node 2 free: 30627 MB
node 3 cpus: 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127
node 3 size: 0 MB
node 3 free: 0 MB
node distances:
node 0 1 2 3
0: 10 15 42 38
1: 15 10 38 33
2: 42 38 10 15
3: 38 33 15 10
[root@SL26GA hugemmap]# numactl --cpunodebind=0 ./hugemmap10
tst_hugepage.c:84: TINFO: 6 hugepage(s) reserved
tst_tmpdir.c:308: TINFO: Using /tmp/LTP_hug9CXa7r as tmpdir (tmpfs filesystem)
tst_test.c:1233: TINFO: Mounting none to /tmp/LTP_hug9CXa7r/hugetlbfs fstyp=hugetlbfs flags=0
tst_test.c:2065: TINFO: LTP version: 20260529
tst_test.c:2068: TINFO: Tested kernel: 6.6.145-9.sl26.x86_64 #1 SMP Thu Sep 3 11:08:39 CST 2026 x86_64
tst_kconfig.c:90: TINFO: Parsing kernel config '/proc/config.gz'
tst_test.c:1893: TINFO: Overall timeout per run is 0h 00m 30s
hugemmap10.c:457: TINFO: Base pool size: 0
hugemmap10.c:384: TINFO: Clean...
hugemmap10.c:435: TINFO: OK
hugemmap10.c:384: TINFO: Untouched, shared...
hugemmap10.c:435: TINFO: OK
hugemmap10.c:384: TINFO: Untouched, private...
hugemmap10.c:435: TINFO: OK
hugemmap10.c:384: TINFO: Touched, shared...
hugemmap10.c:435: TINFO: OK
hugemmap10.c:384: TINFO: Touched, private...
hugemmap10.c:435: TINFO: OK
hugemmap10.c:457: TINFO: Base pool size: 1
hugemmap10.c:384: TINFO: Clean...
hugemmap10.c:435: TINFO: OK
hugemmap10.c:384: TINFO: Untouched, shared...
hugemmap10.c:435: TINFO: OK
hugemmap10.c:384: TINFO: Untouched, private...
hugemmap10.c:435: TINFO: OK
hugemmap10.c:384: TINFO: Touched, shared...
hugemmap10.c:435: TINFO: OK
hugemmap10.c:384: TINFO: Touched, private...
hugemmap10.c:435: TINFO: OK
hugemmap10.c:457: TINFO: Base pool size: 2
hugemmap10.c:384: TINFO: Clean...
hugemmap10.c:435: TINFO: OK
hugemmap10.c:384: TINFO: Untouched, shared...
hugemmap10.c:435: TINFO: OK
hugemmap10.c:384: TINFO: Untouched, private...
hugemmap10.c:435: TINFO: OK
hugemmap10.c:384: TINFO: Touched, shared...
hugemmap10.c:435: TINFO: OK
hugemmap10.c:384: TINFO: Touched, private...
hugemmap10.c:435: TINFO: OK
hugemmap10.c:457: TINFO: Base pool size: 3
hugemmap10.c:384: TINFO: Clean...
hugemmap10.c:435: TINFO: OK
hugemmap10.c:384: TINFO: Untouched, shared...
hugemmap10.c:435: TINFO: OK
hugemmap10.c:384: TINFO: Untouched, private...
hugemmap10.c:435: TINFO: OK
hugemmap10.c:384: TINFO: Touched, shared...
hugemmap10.c:435: TINFO: OK
hugemmap10.c:384: TINFO: Touched, private...
hugemmap10.c:435: TINFO: OK
hugemmap10.c:500: TPASS: Hugepages Counters works as expected.
Summary:
passed 1
failed 0
broken 0
skipped 0
warnings 0
[root@SL26GA hugemmap]# numactl --cpunodebind=2 ./hugemmap10
tst_hugepage.c:84: TINFO: 6 hugepage(s) reserved
tst_tmpdir.c:308: TINFO: Using /tmp/LTP_hugVJVuKk as tmpdir (tmpfs filesystem)
tst_test.c:1233: TINFO: Mounting none to /tmp/LTP_hugVJVuKk/hugetlbfs fstyp=hugetlbfs flags=0
tst_test.c:2065: TINFO: LTP version: 20260529
tst_test.c:2068: TINFO: Tested kernel: 6.6.145-9.sl26.x86_64 #1 SMP Thu Sep 3 11:08:39 CST 2026 x86_64
tst_kconfig.c:90: TINFO: Parsing kernel config '/proc/config.gz'
tst_test.c:1893: TINFO: Overall timeout per run is 0h 00m 30s
hugemmap10.c:457: TINFO: Base pool size: 0
hugemmap10.c:384: TINFO: Clean...
hugemmap10.c:435: TINFO: OK
hugemmap10.c:384: TINFO: Untouched, shared...
hugemmap10.c:435: TINFO: OK
hugemmap10.c:384: TINFO: Untouched, private...
hugemmap10.c:435: TINFO: OK
hugemmap10.c:384: TINFO: Touched, shared...
hugemmap10.c:435: TINFO: OK
hugemmap10.c:384: TINFO: Touched, private...
hugemmap10.c:435: TINFO: OK
hugemmap10.c:457: TINFO: Base pool size: 1
hugemmap10.c:384: TINFO: Clean...
hugemmap10.c:435: TINFO: OK
hugemmap10.c:384: TINFO: Untouched, shared...
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
Summary:
passed 0
failed 3
broken 0
skipped 0
warnings 0
--
Regards,
Li Wang
--
Mailing list info: https://lists.linux.it/listinfo/ltp
next prev parent reply other threads:[~2026-09-16 9:38 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-14 3:23 [LTP] [PATCH] hugemmap10: Account for memory policy in counter checks Huaisheng Ye
2026-09-14 12:03 ` [LTP] " linuxtestproject.agent
2026-09-29 2:19 ` Huaisheng Ye
2026-09-16 8:48 ` [LTP] [PATCH] " Li Wang
2026-09-16 9:37 ` Li Wang [this message]
2026-09-17 8:42 ` Huaisheng Ye
2026-09-17 8:40 ` Huaisheng Ye
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aqpjZsOCq-jDfks_@linux.dev \
--to=li.wang@linux.dev \
--cc=ltp@lists.linux.it \
--cc=pvorel@suse.cz \
--cc=tsahu@linux.ibm.com \
--cc=yehuaisheng@open-hieco.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox