mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "chaithco@redhat.com" <chaithco@redhat.com>
To: muchun.song@linux.dev, osalvador@suse.de, akpm@linux-foundation.org
Cc: david@kernel.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org,  arozansk@redhat.com
Subject: Re: [PATCH 0/2] mm/hugetlb Try to respect mempolicy when calculating surplus huge pages
Date: Tue, 08 Sep 2026 10:17:05 -0600	[thread overview]
Message-ID: <0f3340facc968f1d911c637ef0d305c9282044e0.camel@redhat.com> (raw)
In-Reply-To: <20260707182900.483757-1-chaithco@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 2913 bytes --]

On Tue, 2026-07-07 at 12:28 -0600, Charles Haithcock wrote:
> 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

Any followups on this? Please do let me know if I need to do anything
else to help this patch along! :)

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

      parent reply	other threads:[~2026-09-08 16:17 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-07 18:28 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
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
2026-09-08 16:17 ` chaithco [this message]

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=0f3340facc968f1d911c637ef0d305c9282044e0.camel@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

all inboxes | Powered by JetHome®