All of lore.kernel.org
 help / color / mirror / Atom feed
From: "David Hildenbrand (Red Hat)" <david@kernel.org>
To: Li Wang <liwang@redhat.com>
Cc: akpm@linux-foundation.org, linux-kselftest@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	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:52:08 +0100	[thread overview]
Message-ID: <de5fa614-65c2-43d4-8c3c-549eeeaa5683@kernel.org> (raw)
In-Reply-To: <CAEemH2eH0a6vHhv80hDcTBxTUYHALrOKjtvWnajCwPk_zLpJ3Q@mail.gmail.com>

On 12/21/25 10:35, Li Wang wrote:
> David Hildenbrand (Red Hat) <david@kernel.org> wrote:
> 
>> 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.
> 
> Yes.
> 
> On an aarch64 64k setup with 512MB hugepages, the test failed earlier
> (hugetlbfs got mounted with an effective size of 0 due to size=256M), so
> write_to_hugetlbfs couldn’t allocate the expected pages. After that, the
> script’s wait loops never observed the target value, so they spun forever.

Okay, so essentially what you fix in patch #3, correct?

It might make sense to reorder #2 and #3, and likely current #3 should 
get a Fixes: tag.

Then you can just briefly describe here that this was previously hit due 
to other tests issues. Although I wonder how much value this patch here 
as after #3 is in. But it looks like a cleanup and the timeout of 60s 
sounds reasonable.

I know the reservation of hugetlb folios can take a rather long time in 
some environments, though.

-- 
Cheers

David

  reply	other threads:[~2025-12-21  9:52 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)
2025-12-21  9:35     ` Li Wang
2025-12-21  9:52       ` David Hildenbrand (Red Hat) [this message]
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=de5fa614-65c2-43d4-8c3c-549eeeaa5683@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 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.