Re: [PATCH] ACPI: NUMA: Only parse CFMWS at boot when CXL_ACPI is on

[Alison Schofield <alison.schofield@intel.com>]

On Wed, Mar 04, 2026 at 05:33:26PM -0500, Gregory Price wrote:
> On Thu, Mar 05, 2026 at 10:33:42AM +1300, Kai Huang wrote:
> > 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'.
> > 

> 
> Is this a Linux issue or a Firmware issue?

IIUC BIOS creates the CEDT based on the hardware it 'sees' as present.

This patch is describing the case (weird as it seems to me) where we
then boot a system with ACPI and NUMA enabled but CXL_ACPI disabled.

So, I don't think we can blame BIOS.

> 
> Is GNR exporting more CFMWS than it should?
Not sure of any limits on flavors of CFMWS's a BIOS can offer.
If BIOS can carve out a window, it can create a CFMWS.
Not clear how that matters to the issue.

> 
> Is your SRAT missing entries for CFMWS that are otherwise present?
> 
> Are the CFMWS empty? (is that even valid)

Why this line of questioning ;)  I see the problem as a bit simpler.
We have other code that tells us if the CFMWS's are valid, etc, but
the point here is, we are not going to use these CFMWS's so stop
the parse as early as possible, like right here as Kai has done.

> 
> > 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
> > 
> 
> This is a good effect, but I still question the premise.
> 
> We don't usually want #ifdef's inside of .c files if we can avoid it.

I thought similar, but for early init and static helpers, this 
#if IS_ENABLE(..) wrapper is common.


Reviewed-by: Alison Schofield <alison.schofield@intel.com>


> 
> ~Gregory