From: Joshua Hahn <joshua.hahnjy@gmail.com>
To: Charles Haithcock <chaithco@redhat.com>
Cc: muchun.song@linux.dev, osalvador@suse.de,
akpm@linux-foundation.org, david@kernel.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, arozansk@redhat.com
Subject: Re: [PATCH 1/2] mm/hugetlb: Prefer mempolicy nodes for calcuating surplus hugepage reservation
Date: Tue, 7 Jul 2026 12:33:57 -0700 [thread overview]
Message-ID: <20260707193358.3434034-1-joshua.hahnjy@gmail.com> (raw)
In-Reply-To: <20260707182900.483757-2-chaithco@redhat.com>
On Tue, 7 Jul 2026 12:28:55 -0600 Charles Haithcock <chaithco@redhat.com> wrote:
> Currently, reserving surplus hugetlb pages in a mempolicy still use
> global counters for calculating how many hugetlb pages to reserve.
> Modify this to consider the nodes in the mempolicy first but fall back
> to all possible nodes.
Hi Charles, thank you for the patch, this looks good to me!
Personally I like the description of the commit in the cover letter
because it provides a bit more context. Do other reviewers have
thoughts on this? In any case, the code LGTM : -)
Reviewed-by: Joshua Hahn <joshua.hahnjy@gmail.com>
BTW this is a little strange but Sashiko seems to have failed to apply
this patch [1] which is strange because when applying on the exact
same commit db6ed2a3d3106 "mm/swap, PM: hibernate: atomically replace hibernation pin"
as Sashiko tried, it worked & compiled for me with no errors at all...
[1] https://sashiko.dev/#/patchset/20260707182900.483757-1-chaithco%40redhat.com
Sashiko's error log:
Trying baseline: mm/mm-new (db6ed2a3d31068ca5577466591b2521dee0508ca)
Patch 41962/2 (ID: 108031) failed to apply.
Application failed.
> Suggested-by: Joshua Hahn <joshua.hahnjy@gmail.com>
> Signed-off-by: Charles Haithcock <chaithco@redhat.com>
> ---
>
> - 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/
>
> mm/hugetlb.c | 42 ++++++++++++++++++++++--------------------
> 1 file changed, 22 insertions(+), 20 deletions(-)
>
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index f24bf49be0..f5e678e997 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -2255,6 +2255,23 @@ static nodemask_t *policy_mbind_nodemask(gfp_t gfp)
> return NULL;
> }
>
> +static unsigned int allowed_mems_nr(struct hstate *h)
> +{
> + int node;
> + unsigned int nr = 0;
> + nodemask_t *mbind_nodemask;
> + unsigned int *array = h->free_huge_pages_node;
> + gfp_t gfp_mask = htlb_alloc_mask(h);
> +
> + mbind_nodemask = policy_mbind_nodemask(gfp_mask);
> + for_each_node_mask(node, cpuset_current_mems_allowed) {
> + if (!mbind_nodemask || node_isset(node, *mbind_nodemask))
> + nr += array[node];
> + }
> +
> + return nr;
> +}
> +
> /*
> * Increase the hugetlb pool such that it can accommodate a reservation
> * of size 'delta'.
> @@ -2277,7 +2294,8 @@ static int gather_surplus_pages(struct hstate *h, long delta)
> alloc_nodemask = cpuset_current_mems_allowed;
>
> lockdep_assert_held(&hugetlb_lock);
> - needed = (h->resv_huge_pages + delta) - h->free_huge_pages;
> + needed = max_t(long, (delta - allowed_mems_nr(h)),
> + ((h->resv_huge_pages + delta) - h->free_huge_pages));
> if (needed <= 0) {
> h->resv_huge_pages += delta;
> return 0;
> @@ -2311,8 +2329,9 @@ static int gather_surplus_pages(struct hstate *h, long delta)
> * because either resv_huge_pages or free_huge_pages may have changed.
> */
> spin_lock_irq(&hugetlb_lock);
> - needed = (h->resv_huge_pages + delta) -
> - (h->free_huge_pages + allocated);
> + needed = max_t(long, ((delta - allowed_mems_nr(h)) - allocated),
> + ((h->resv_huge_pages + delta) -
> + (h->free_huge_pages + allocated)));
> if (needed > 0) {
> if (alloc_ok)
> goto retry;
> @@ -4513,23 +4532,6 @@ static int __init hugepage_alloc_threads_setup(char *s)
> }
> __setup("hugepage_alloc_threads=", hugepage_alloc_threads_setup);
>
> -static unsigned int allowed_mems_nr(struct hstate *h)
> -{
> - int node;
> - unsigned int nr = 0;
> - nodemask_t *mbind_nodemask;
> - unsigned int *array = h->free_huge_pages_node;
> - gfp_t gfp_mask = htlb_alloc_mask(h);
> -
> - mbind_nodemask = policy_mbind_nodemask(gfp_mask);
> - for_each_node_mask(node, cpuset_current_mems_allowed) {
> - if (!mbind_nodemask || node_isset(node, *mbind_nodemask))
> - nr += array[node];
> - }
> -
> - return nr;
> -}
> -
> void hugetlb_report_meminfo(struct seq_file *m)
> {
> struct hstate *h;
> --
> 2.55.0
next prev parent reply other threads:[~2026-07-07 19:34 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-07 18:28 [PATCH 0/2] mm/hugetlb Try to respect mempolicy when calculating surplus huge pages Charles Haithcock
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 [this message]
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=20260707193358.3434034-1-joshua.hahnjy@gmail.com \
--to=joshua.hahnjy@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=arozansk@redhat.com \
--cc=chaithco@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