From: Kai Huang <kai.huang@intel.com>
To: rafael@kernel.org, lenb@kernel.org, dan.j.williams@intel.com,
alison.schofield@intel.com
Cc: akpm@linux-foundation.org, nunodasneves@linux.microsoft.com,
xueshuai@linux.alibaba.com, thorsten.blum@linux.dev,
gourry@gourry.net, wangyuquan1236@phytium.com.cn,
linux-acpi@vger.kernel.org, linux-cxl@vger.kernel.org,
linux-kernel@vger.kernel.org, Kai Huang <kai.huang@intel.com>
Subject: [PATCH v2] ACPI: NUMA: Only parse CFMWS at boot when CXL_ACPI is on
Date: Mon, 9 Mar 2026 11:23:13 +1300 [thread overview]
Message-ID: <20260308222313.14014-1-kai.huang@intel.com> (raw)
On CXL platforms, the Static Resource Affinity Table (SRAT) may not
cover memory affinity information for all the CXL memory regions. Since
each CXL memory region is enumerated via a CXL Fixed Memory Window
Structure (CFMWS), during early boot the kernel parses the CFMWS tables
to find all CXL memory regions and sets a NUMA node for each of them.
This memory affinity information of CXL memory regions is later used by
the CXL ACPI driver.
The CFMWS table doesn't provide the memory affinity information either.
Currently the kernel assigns a 'faked' NUMA node for each CXL memory
region, starting from the next node of the highest node that is
enumerated via the SRAT. This can potentially increase the maximum NUMA
node ID of the platform ('nr_node_ids') a lot. E.g., on a GNR platform
with 4 NUMA nodes and 18 CFMWS tables, this bumps the 'nr_node_ids' to
22.
Increasing the 'nr_node_ids' has side effects. For instance, it is
widely used by the kernel for "highest possible NUMA node" based memory
allocations. It also impacts userspace ABIs, e.g., some NUMA memory
related system calls such as 'get_mempolicy' which requires 'maxnode'
not being smaller than the 'nr_node_ids'.
Currently parsing CFMWS tables and assigning faked NUMA node at boot is
done unconditionally. However, if the CXL ACPI driver is not enabled,
there will be no user of such memory affinity information of CXL memory
regions.
Change to only parsing the CFMWS tables at boot when CXL_ACPI is enabled
in Kconfig to avoid the unnecessary cost of bumping up 'nr_node_ids'.
E.g., on the aforementioned GNR platform, the "Slab" in /proc/meminfo is
reduced with this change (when CXL_ACPI is off):
w/ this change w/o
Slab 900488 kB 923660 kB
Signed-off-by: Kai Huang <kai.huang@intel.com>
---
v1 -> v2:
- Use Dan's suggestion to simplify the diff:
https://lore.kernel.org/linux-cxl/69a8dc7ca72c2_2f4a10026@dwillia2-mobl4.notmuch/
Hi Alison, Gregory,
I didn't add your RB since the code now is different from that you
reviewed. Appreciate if you can take a look again and provide the tag
if the patch looks good to you.
---
drivers/acpi/numa/srat.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/numa/srat.c b/drivers/acpi/numa/srat.c
index aa87ee1583a4..62d4a8df0b8c 100644
--- a/drivers/acpi/numa/srat.c
+++ b/drivers/acpi/numa/srat.c
@@ -654,8 +654,11 @@ int __init acpi_numa_init(void)
}
last_real_pxm = fake_pxm;
fake_pxm++;
- acpi_table_parse_cedt(ACPI_CEDT_TYPE_CFMWS, acpi_parse_cfmws,
- &fake_pxm);
+
+ /* No need to expand numa nodes if CXL is disabled */
+ if (IS_ENABLED(CONFIG_CXL_ACPI))
+ acpi_table_parse_cedt(ACPI_CEDT_TYPE_CFMWS, acpi_parse_cfmws,
+ &fake_pxm);
if (cnt < 0)
return cnt;
base-commit: 084f843093bee5563b179fd4b630122ba820e0c7
--
2.53.0
next reply other threads:[~2026-03-08 22:23 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-08 22:23 Kai Huang [this message]
2026-03-09 0:06 ` [PATCH v2] ACPI: NUMA: Only parse CFMWS at boot when CXL_ACPI is on Gregory Price
2026-03-09 11:52 ` Jonathan Cameron
2026-03-09 17:13 ` Alison Schofield
2026-03-16 18:11 ` Dave Jiang
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=20260308222313.14014-1-kai.huang@intel.com \
--to=kai.huang@intel.com \
--cc=akpm@linux-foundation.org \
--cc=alison.schofield@intel.com \
--cc=dan.j.williams@intel.com \
--cc=gourry@gourry.net \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-cxl@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nunodasneves@linux.microsoft.com \
--cc=rafael@kernel.org \
--cc=thorsten.blum@linux.dev \
--cc=wangyuquan1236@phytium.com.cn \
--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