From: Gregory Price <gourry@gourry.net>
To: Mike Rapoport <rppt@kernel.org>
Cc: linux-mm@kvack.org, x86@kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
driver-core@lists.linux.dev, kernel-team@meta.com,
corbet@lwn.net, skhan@linuxfoundation.org,
dave.hansen@linux.intel.com, luto@kernel.org,
peterz@infradead.org, tglx@kernel.org, mingo@redhat.com,
bp@alien8.de, hpa@zytor.com, rafael@kernel.org, lenb@kernel.org,
gregkh@linuxfoundation.org, dakr@kernel.org,
akpm@linux-foundation.org, rdunlap@infradead.org,
feng.tang@linux.alibaba.com, dapeng1.mi@linux.intel.com,
elver@google.com, kuba@kernel.org, ebiggers@kernel.org,
lirongqing@baidu.com, paulmck@kernel.org, dave.jiang@intel.com,
jic23@kernel.org, xueshuai@linux.alibaba.com,
kai.huang@intel.com
Subject: Re: [RFC PATCH 1/3] mm/numa: add exclusive node pool and numa=standby boot parameter
Date: Thu, 11 Jun 2026 10:04:01 -0400 [thread overview]
Message-ID: <airAUSrNjbSEwuti@gourry-fedora-PF4VCD3F> (raw)
In-Reply-To: <aip5IWmxg9CWg8hQ@kernel.org>
On Thu, Jun 11, 2026 at 12:00:17PM +0300, Mike Rapoport wrote:
> > 1) Can we do dynamic addition of nodes?
> >
> > Not Trivially
> >
> > Some services utilize num_possible_nodes() as a static value to
> > calculate the amount of resources to use at runtime (bpf, md/raid5).
> >
> > Example: futex_init uses num_possible_nodes() as part of its
> > hashsize calculation during __init.
>
> AFAIU, we don't add the additional nodes for generic hotplug memory but
> rather for exclusive use of by drivers/applications that are aware of these
> nodes.
The intent is to use for "non-generic" hotplug (see the whole private
node series [1]), which would eventually still use the hotplug mechanism
just not for generic memory.
[1] https://lore.kernel.org/linux-mm/20260222084842.1824063-1-gourry@gourry.net/
> Wouldn't adding them to possible nodes actually skew the calculation of the
> resources by the services utilizing num_possible_nodes()?
>
> With the futex_init() example, won't be hashsize scaled down two much
> because we've added these special nodes to the possible mask?
>
The result is the same as BIOS reserving nodes with PXM entries that
don't get used. The CXL ACPI Tables do this for CXL Fixed Memory
Windows that may never be hotplugged.
So really i think you're pointing out that futex_init() here probably
shouldn't be using num_possible_nodes?
~Gregory
next prev parent reply other threads:[~2026-06-11 14:04 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-10 1:45 [RFC PATCH 0/3] mm/numa: reserve standby NUMA nodes for runtime claiming Gregory Price
2026-06-10 1:45 ` [RFC PATCH 1/3] mm/numa: add exclusive node pool and numa=standby boot parameter Gregory Price
2026-06-11 9:00 ` Mike Rapoport
2026-06-11 14:04 ` Gregory Price [this message]
2026-06-14 9:08 ` Mike Rapoport
2026-06-23 16:36 ` Gregory Price
2026-07-02 11:09 ` Mike Rapoport
2026-07-02 14:43 ` Gregory Price
2026-06-10 1:45 ` [RFC PATCH 2/3] acpi/numa: add CONFIG_ACPI_NUMA_STANDBY_NODES Gregory Price
2026-06-10 1:45 ` [RFC PATCH 3/3] acpi/numa: add CONFIG_ACPI_NUMA_ADD_CFMWS_NODES Gregory Price
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=airAUSrNjbSEwuti@gourry-fedora-PF4VCD3F \
--to=gourry@gourry.net \
--cc=akpm@linux-foundation.org \
--cc=bp@alien8.de \
--cc=corbet@lwn.net \
--cc=dakr@kernel.org \
--cc=dapeng1.mi@linux.intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=dave.jiang@intel.com \
--cc=driver-core@lists.linux.dev \
--cc=ebiggers@kernel.org \
--cc=elver@google.com \
--cc=feng.tang@linux.alibaba.com \
--cc=gregkh@linuxfoundation.org \
--cc=hpa@zytor.com \
--cc=jic23@kernel.org \
--cc=kai.huang@intel.com \
--cc=kernel-team@meta.com \
--cc=kuba@kernel.org \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lirongqing@baidu.com \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=paulmck@kernel.org \
--cc=peterz@infradead.org \
--cc=rafael@kernel.org \
--cc=rdunlap@infradead.org \
--cc=rppt@kernel.org \
--cc=skhan@linuxfoundation.org \
--cc=tglx@kernel.org \
--cc=x86@kernel.org \
--cc=xueshuai@linux.alibaba.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox