[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ad1ff365-4160-87b9-4199-ace5ff1250e1@intel.com>
Date: Fri, 1 Sep 2023 10:18:20 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: Steve Wahl <steve.wahl@....com>,
Dimitri Sivanich <dimitri.sivanich@....com>,
Russ Anderson <russ.anderson@....com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
"H. Peter Anvin" <hpa@...or.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86/platform/uv: Use alternate source for socket to node
data
On 8/7/23 07:17, Steve Wahl wrote:
> When nr_cpus is set to a smaller number than actually present, the
> cpu_to_node() mapping information for unused CPUs is not available to
> build_socket_tables(). This results in an incomplete table and will
> later cause use of a -1 value for some array indexing, and eventual
> kernel page faults.
>
> Switch to using the __apicid_to_node array, which still contains all
> the information mapping apicids to nodes, even for CPUs disabled with
> a reduced nr_cpus setting.
Before, the lookup went:
CPU => APICID => SOCKET
But when the CPU wasn't present, there wasn't a way to start this lookup.
So, instead of looping over all CPUs, looking up their APICIDs and
mapping those to sockets, just take CPUs out of the equation entirely.
Loop over all APICIDs which are mapped to a valid NUMA node. Then just
extract the socket-id from the APICID.
Right?
That seems sane enough. It's also way less code than the previous approach.
Powered by blists - more mailing lists