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

[Haifeng Xu <haifeng.xu@shopee.com>]

On 2026/3/5 08:14, Huang, Kai wrote:
> On Wed, 2026-03-04 at 18:56 -0500, Gregory Price wrote:
>> On Wed, Mar 04, 2026 at 03:20:11PM -0800, Alison Schofield wrote:
>>> 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.
>>>
>>
>> Mostly i'm wondering if this issue should be dealt with in the acpi code
>> or if the issue is that we just don't want to figure out how to
>> lazy-create these things instead of always creating them at __init.
>>
>> it does seem rational to build out support for CEDT entries if CXL_ACPI
>> is built out, but this also means you can't otherwise load modules that
>> would have made use of this information.
> 
> Besides CXL_ACPI, is there any other module(s) that uses this information
> for these CXL memory regions?
> 
>>
>> This basically says if specifically CXL_ACPI is built out, the NUMA
>> structure is forever lost - even though it's accurately described by
>> BIOS.  
>>
> 
> The normal NUMA info described in SRAT is still there.  It only avoids
> detecting CFMWS, which doesn't provide any NUMA info actually -- that's why
> kernel assigns a 'faked' NUMA node for each of them.

Hi Kai, we met some performance issues when creating pods because of too much
possible node without cxl memory inserted in our machine (machine Intel(R) Xeon(R) 6746E).
This patch can workaround our issue.

By the way, If insert real cxl memory but disable CXL_ACPI, how the kernel
initilaizes the cxl memory and assigns the numa node? can you provide the
related kernel souce code?

Thanks!


> 
> So we are not losing anything AFAICT.