From: "David Hildenbrand (Red Hat)" <david@kernel.org>
To: Li Wang <liwang@redhat.com>,
akpm@linux-foundation.org, linux-kselftest@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Cc: Mark Brown <broonie@kernel.org>, Shuah Khan <shuah@kernel.org>,
Waiman Long <longman@redhat.com>
Subject: Re: [PATCH v2 2/3] selftests/mm/charge_reserved_hugetlb.sh: add waits with timeout helper
Date: Sun, 21 Dec 2025 10:15:35 +0100 [thread overview]
Message-ID: <74414ade-63fb-47ff-adda-903949468b88@kernel.org> (raw)
In-Reply-To: <20251221085810.3163919-3-liwang@redhat.com>
On 12/21/25 09:58, Li Wang wrote:
> The hugetlb cgroup usage wait loops in charge_reserved_hugetlb.sh were
> unbounded and could hang forever if the expected cgroup file value never
> appears (e.g. due to bugs, timing issues, or unexpected behavior).
Did you actually hit that in practice? Just wondering.
>
> --- Error log ---
> # uname -r
> 6.12.0-xxx.el10.aarch64+64k
>
> # ls /sys/kernel/mm/hugepages/hugepages-*
> hugepages-16777216kB/ hugepages-2048kB/ hugepages-524288kB/
>
> #./charge_reserved_hugetlb.sh -cgroup-v2
> # -----------------------------------------
> ...
> # nr hugepages = 10
> # writing cgroup limit: 5368709120
> # writing reseravation limit: 5368709120
> ...
> # write_to_hugetlbfs: Error mapping the file: Cannot allocate memory
> # Waiting for hugetlb memory reservation to reach size 2684354560.
> # 0
> # Waiting for hugetlb memory reservation to reach size 2684354560.
> # 0
> # Waiting for hugetlb memory reservation to reach size 2684354560.
> # 0
> # Waiting for hugetlb memory reservation to reach size 2684354560.
> # 0
> # Waiting for hugetlb memory reservation to reach size 2684354560.
> # 0
> # Waiting for hugetlb memory reservation to reach size 2684354560.
> # 0
> ...
>
> Introduce a small helper, wait_for_file_value(), and use it for:
> - waiting for reservation usage to drop to 0,
> - waiting for reservation usage to reach a given size,
> - waiting for fault usage to reach a given size.
>
> This makes the waits consistent and adds a hard timeout (120 tries with
> 0.5s sleep) so the test fails instead of stalling indefinitely.
>
> Signed-off-by: Li Wang <liwang@redhat.com>
> Cc: David Hildenbrand <david@kernel.org>
> Cc: Mark Brown <broonie@kernel.org>
> Cc: Shuah Khan <shuah@kernel.org>
> Cc: Waiman Long <longman@redhat.com>
> ---
> .../selftests/mm/charge_reserved_hugetlb.sh | 47 ++++++++++---------
> 1 file changed, 26 insertions(+), 21 deletions(-)
>
> diff --git a/tools/testing/selftests/mm/charge_reserved_hugetlb.sh b/tools/testing/selftests/mm/charge_reserved_hugetlb.sh
> index e1fe16bcbbe8..249a5776c074 100755
> --- a/tools/testing/selftests/mm/charge_reserved_hugetlb.sh
> +++ b/tools/testing/selftests/mm/charge_reserved_hugetlb.sh
> @@ -100,7 +100,7 @@ function setup_cgroup() {
> echo writing cgroup limit: "$cgroup_limit"
> echo "$cgroup_limit" >$cgroup_path/$name/hugetlb.${MB}MB.$fault_limit_file
>
> - echo writing reseravation limit: "$reservation_limit"
> + echo writing reservation limit: "$reservation_limit"
> echo "$reservation_limit" > \
> $cgroup_path/$name/hugetlb.${MB}MB.$reservation_limit_file
>
> @@ -112,41 +112,46 @@ function setup_cgroup() {
> fi
> }
>
> +function wait_for_file_value() {
> + local path="$1"
> + local expect="$2"
> + local max_tries="120"
> +
> + local i cur
I would just move "cur" into the loop; I don't see a reason to print it
on the error path when you printed the value on the last "Waiting" line?
local cur="$(cat "$path")"
Also, not sure if you really need the "local i" here.
What if the path does not exist, do we want to catch that earlier and
bail out instead of letting "cat" fail here?
> + for ((i=1; i<=max_tries; i++)); do
> + cur="$(cat "$path")"
> + if [[ "$cur" == "$expect" ]]; then
> + return 0
> + fi
> + echo "Waiting for $path to become '$expect' (current: '$cur') (try $i/$max_tries)"
> + sleep 0.5
Any reason we don't go for the more intuitive "wait 1s" - max 60s wait?
> + done
Nothing else jumped at me.
--
Cheers
David
next prev parent reply other threads:[~2025-12-21 9:15 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-21 8:58 [PATCH v2 0/3] selftests/mm: hugetlb cgroup charging: robustness fixes Li Wang
2025-12-21 8:58 ` [PATCH v2 1/3] selftests/mm/write_to_hugetlbfs: parse -s as size_t Li Wang
2025-12-21 9:01 ` David Hildenbrand (Red Hat)
2025-12-21 8:58 ` [PATCH v2 2/3] selftests/mm/charge_reserved_hugetlb.sh: add waits with timeout helper Li Wang
2025-12-21 9:15 ` David Hildenbrand (Red Hat) [this message]
2025-12-21 9:35 ` Li Wang
2025-12-21 9:52 ` David Hildenbrand (Red Hat)
2025-12-21 10:08 ` Li Wang
2025-12-21 8:58 ` [PATCH v2 3/3] selftests/mm/charge_reserved_hugetlb: fix hugetlbfs mount size for large hugepages Li Wang
2025-12-21 9:17 ` David Hildenbrand (Red Hat)
2025-12-21 9:44 ` Li Wang
2025-12-21 9:49 ` David Hildenbrand (Red Hat)
2025-12-21 11:56 ` Li Wang
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=74414ade-63fb-47ff-adda-903949468b88@kernel.org \
--to=david@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=broonie@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=liwang@redhat.com \
--cc=longman@redhat.com \
--cc=shuah@kernel.org \
/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