All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.