All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oscar Salvador <osalvador@suse.de>
To: Luiz Capitulino <luizcap@redhat.com>
Cc: linux-kernel@vger.kernel.org, yaozhenguo1@gmail.com,
	muchun.song@linux.dev, linux-mm@kvack.org,
	akpm@linux-foundation.org, david@redhat.com, rppt@kernel.org,
	fvdl@google.com
Subject: Re: [PATCH] mm: hugetlb: avoid fallback for specific node allocation of 1G pages
Date: Tue, 11 Feb 2025 10:06:54 +0100	[thread overview]
Message-ID: <Z6sTLjKlX39s0Mo_@localhost.localdomain> (raw)
In-Reply-To: <20250211034856.629371-1-luizcap@redhat.com>

On Mon, Feb 10, 2025 at 10:48:56PM -0500, Luiz Capitulino wrote:
> When using the HugeTLB kernel command-line to allocate 1G pages from
> a specific node, such as:
> 
>    default_hugepagesz=1G hugepages=1:1
> 
> If node 1 happens to not have enough memory for the requested number of
> 1G pages, the allocation falls back to other nodes. A quick way to
> reproduce this is by creating a KVM guest with a memory-less node and
> trying to allocate 1 1G page from it. Instead of failing, the allocation
> will fallback to other nodes.
> 
> This defeats the purpose of node specific allocation. Also, specific
> node allocation for 2M pages don't have this behavior: the allocation
> will just fail for the pages it can't satisfy.
> 
> This issue happens because HugeTLB calls memblock_alloc_try_nid_raw()
> for 1G boot-time allocation as this function falls back to other nodes
> if the allocation can't be satisfied. Use memblock_alloc_exact_nid_raw()
> instead, which ensures that the allocation will only be satisfied from
> the specified node.
> 
> Fixes: b5389086ad7b ("hugetlbfs: extend the definition of hugepages parameter to support node allocation")
> 
> Signed-off-by: Luiz Capitulino <luizcap@redhat.com>

Acked-by: Oscar Salvador <osalvador@suse.de>

This was discussed yesterday in [1], ccing Frank for awareness.

[1] https://patchwork.kernel.org/project/linux-mm/patch/20250206185109.1210657-6-fvdl@google.com/


-- 
Oscar Salvador
SUSE Labs


  reply	other threads:[~2025-02-11 14:44 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-11  3:48 [PATCH] mm: hugetlb: avoid fallback for specific node allocation of 1G pages Luiz Capitulino
2025-02-11  9:06 ` Oscar Salvador [this message]
2025-02-11 14:51   ` Luiz Capitulino
2025-02-11 16:49     ` Frank van der Linden
2025-02-11 13:49 ` David Hildenbrand

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=Z6sTLjKlX39s0Mo_@localhost.localdomain \
    --to=osalvador@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=david@redhat.com \
    --cc=fvdl@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=luizcap@redhat.com \
    --cc=muchun.song@linux.dev \
    --cc=rppt@kernel.org \
    --cc=yaozhenguo1@gmail.com \
    /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.