mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Dave Hansen <dave.hansen@intel.com>
To: Steve Wahl <steve.wahl@hpe.com>,
	Dimitri Sivanich <dimitri.sivanich@hpe.com>,
	Russ Anderson <russ.anderson@hpe.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] x86/platform/uv: Use alternate source for socket to node data
Date: Fri, 1 Sep 2023 10:18:20 -0700	[thread overview]
Message-ID: <ad1ff365-4160-87b9-4199-ace5ff1250e1@intel.com> (raw)
In-Reply-To: <20230807141730.1117278-1-steve.wahl@hpe.com>

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.

  parent reply	other threads:[~2023-09-01 17:18 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-07 14:17 Steve Wahl
2023-08-28 21:22 ` Steve Wahl
2023-09-01 17:18 ` Dave Hansen [this message]
2023-09-01 19:01   ` Steve Wahl
2023-09-05 15:01     ` Steve Wahl
2023-09-07 20:57       ` Dave Hansen
2023-09-07 21:25         ` Steve Wahl
2023-09-07 21:32           ` Dave Hansen
2023-09-07 21:43             ` Steve Wahl

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=ad1ff365-4160-87b9-4199-ace5ff1250e1@intel.com \
    --to=dave.hansen@intel.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=dimitri.sivanich@hpe.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=russ.anderson@hpe.com \
    --cc=steve.wahl@hpe.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /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

all inboxes | Powered by JetHome®