From: Charles Haithcock <chaithco@redhat.com>
To: muchun.song@linux.dev, osalvador@suse.de, akpm@linux-foundation.org
Cc: Charles Haithcock <chaithco@redhat.com>,
david@kernel.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, arozansk@redhat.com
Subject: [PATCH 0/2] mm/hugetlb Try to respect mempolicy when calculating surplus huge pages
Date: Tue, 7 Jul 2026 12:28:54 -0600 [thread overview]
Message-ID: <20260707182900.483757-1-chaithco@redhat.com> (raw)
Presently, when calculating how many huge pages are needed when
reserving surplus huge pages, the global count of free huge pages
is used. When reserving with a mempolicy, the global count of free huge
pages is used even if some/all of those free huge pages are on numa
nodes outside of the mempolicy.
Reserving surplus huge pages is ultimately best effort even without a
mempolicy. Restrictions from cpusets and mempolicies further complicate
calculating correct numbers of surplus huge pages to reserve and
maintaining which nodes those reservations belong to (see the comment in
`hugetlb_acct_memory`).
However, we can do a little better when reserving surplus huge pages
with a mempolicy. This patch changes how to calculate the necessary
amount of surplus huge pages to reserve by considering the max of either
the amount of free huge pages on nodes in the mempolicy or the global
amount of free huge pages. We may still attempt to reserve huge pages
outside the mempolicy, however, we end up being more likely to reserve
from nodes in the mempolicy.
- v1: Modified `needed` calculation to use `allowed_mems_nr(h)` in order
to consider free hugetlb pages in our mempolicy.
- v2: Folded in Joshua Hahn's recommendation [1] to further modify
`needed` calculation to take the max of either the available hugetlb
pages in the mempolicy or the globally available hugetlb pages. Allows
allocations to prioritize nodes in the mempolicy but can still fall
back to offnode allocations. Also added selftests to check only for
the edgecase which caused this to initially be reported and sanity
checks.
- v3: Split the change and tests into separate patches and clean up code
to better align with kernel style guidelines. Likewise, fold in Usama
Arif's correction [2].
[1] https://lore.kernel.org/all/20260602152022.2673803-1-joshua.hahnjy@gmail.com/
[2] https://lore.kernel.org/linux-mm/20260624144600.8159-1-usama.arif@linux.dev/
Charles Haithcock (2):
mm/hugetlb: Prefer mempolicy nodes for calcuating surplus hugepage
reservation
selftests/mm: add surplus hugetlb mempolicy reservation tests
mm/hugetlb.c | 42 +-
tools/testing/selftests/mm/Makefile | 3 +
.../selftests/mm/hugetlb_surplus_mempolicy.c | 491 ++++++++++++++++++
tools/testing/selftests/mm/run_vmtests.sh | 1 +
4 files changed, 517 insertions(+), 20 deletions(-)
create mode 100644 tools/testing/selftests/mm/hugetlb_surplus_mempolicy.c
--
2.55.0
next reply other threads:[~2026-07-07 18:29 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-07 18:28 Charles Haithcock [this message]
2026-07-07 18:28 ` [PATCH 1/2] mm/hugetlb: Prefer mempolicy nodes for calcuating surplus hugepage reservation Charles Haithcock
2026-07-07 19:33 ` Joshua Hahn
2026-07-08 15:39 ` chaithco
2026-07-09 14:30 ` Joshua Hahn
2026-07-07 18:28 ` [PATCH 2/2] selftests/mm: add surplus hugetlb mempolicy reservation tests Charles Haithcock
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=20260707182900.483757-1-chaithco@redhat.com \
--to=chaithco@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=arozansk@redhat.com \
--cc=david@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=muchun.song@linux.dev \
--cc=osalvador@suse.de \
/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