All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tim Chen <tim.c.chen@linux.intel.com>
To: "Chen, Yu C" <yu.c.chen@intel.com>,
	Peter Zijlstra <peterz@infradead.org>
Cc: linux-kernel@vger.kernel.org, kyle.meyer@hpe.com,
	vinicius.gomes@intel.com, 	brgerst@gmail.com, hpa@zytor.com,
	kprateek.nayak@amd.com, 	patryk.wlazlyn@linux.intel.com,
	rafael.j.wysocki@intel.com, 	russ.anderson@hpe.com,
	zhao1.liu@intel.com, tony.luck@intel.com, x86@kernel.org,
		tglx@kernel.org
Subject: Re: [RFC][PATCH 5/6] x86/topo: Fix SNC topology mess
Date: Thu, 26 Feb 2026 14:11:49 -0800	[thread overview]
Message-ID: <641cb6457fcbb6509351ecb45bdff300540f9f55.camel@linux.intel.com> (raw)
In-Reply-To: <aa0474c49e680a5449f1edb7931afb281a79b4ce.camel@linux.intel.com>

On Thu, 2026-02-26 at 11:00 -0800, Tim Chen wrote:
> On Fri, 2026-02-27 at 01:07 +0800, Chen, Yu C wrote:
> > Hi Peter,
> > 
> > On 2/26/2026 6:49 PM, Peter Zijlstra wrote:
> > > +	int u = __num_nodes_per_package;
> > 
> > Yes, this is much simpler, thanks for the patch!
> > 
> > > +	long d = 0;
> > > +	int x, y;
> > > +
> > > +	/*
> > > +	 * Is this a unit cluster on the trace?
> > > +	 */
> > > +	if ((i / u) == (j / u))
> > > +		return node_distance(i, j);
> > 
> > If the number of nodes per package is 3, we assume that
> > every 3 consecutive nodes are SNC siblings (on the same
> > trace):node0, node1, and node2 are SNC siblings, while
> > node3, node4, and node5 form another group of SNC siblings.
> > 
> > I have a curious thought: could it be possible that
> > node0, node2, and node4 are SNC siblings, and node1,
> > node3, and node5 are another set of SNC siblings instead?
> > 
> > Then I studied the code a little more, node ids are dynamically
> > allocated via the acpi_map_pxm_to_node, so the assignment of node
> > ids depends on the order in which each processor affinity structure
> > is listed in the SRAT table. For example, suppose CPU0 belongs to
> > package0 and CPU1 belongs to package1, but their entries are placed
> > consecutively in the SRAT. In this case, the Proximity Domain of
> > CPU0 would be mapped to node0 via acpi_map_pxm_to_node, and CPU1’s
> > Proximity Domain would be assigned node1. The logic above would
> > then treat them as belonging to the same package, even though they
> > are physically in different packages. However, I believe such a
> > scenario is unlikely to occur in practice in the BIOS and if it
> > happens it should be a BIOS bug if I understand correctly.
> > 
> > 
> 
> May be a good idea to sanity check that the nodes in the first unit cluster
> has the same package id and give a WARNING if that's not the case.
> 
Perhaps something like below

Tim

---
diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index d97f8f4e014c..38384ea5253a 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -511,6 +511,24 @@ static int slit_cluster_distance(int i, int j)
 	int u = __num_nodes_per_package;
 	long d = 0;
 	int x, y;
+	static int valid_slit = 0;
+
+	if (valid_slit == -1)
+		return node_distance(i, j);
+
+	if (valid_slit == 0) {
+		/* Check first nodes in package are grouped together consecutively */
+		for (x = 0; x < u-1 ; x++) {
+			if (topology_physical_package_id(x) !=
+			    topology_physical_package_id(x+1)) {
+				pr_warn("Expect nodes %d and %d to be in the same package",
+						x, x+1);
+				valid_slit = -1;
+				return node_distance(i, j);
+			}
+		}
+		valid_slit = 1;
+	}
 
 	/*
 	 * Is this a unit cluster on the trace?


  reply	other threads:[~2026-02-26 22:11 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-26 10:49 [RFC][PATCH 0/6] x86/topo: SNC Divination Peter Zijlstra
2026-02-26 10:49 ` [RFC][PATCH 1/6] x86/topo: Store extra copy of SRAT table Peter Zijlstra
2026-02-26 10:49 ` [RFC][PATCH 2/6] x86/topo: Add TOPO_NUMA_DOMAIN Peter Zijlstra
2026-02-27 13:19   ` K Prateek Nayak
2026-02-27 14:06     ` Peter Zijlstra
2026-03-02  4:16       ` K Prateek Nayak
2026-03-02 15:10         ` Peter Zijlstra
2026-03-02 15:35           ` K Prateek Nayak
2026-03-02 16:28             ` Peter Zijlstra
2026-02-26 10:49 ` [RFC][PATCH 3/6] x86/topo: Add __num_nodes_per_package Peter Zijlstra
2026-02-26 17:46   ` Kyle Meyer
2026-02-27 11:57     ` Peter Zijlstra
2026-02-26 10:49 ` [RFC][PATCH 4/6] x86/topo: Replace x86_has_numa_in_package Peter Zijlstra
2026-02-26 10:49 ` [RFC][PATCH 5/6] x86/topo: Fix SNC topology mess Peter Zijlstra
2026-02-26 17:07   ` Chen, Yu C
2026-02-26 19:00     ` Tim Chen
2026-02-26 22:11       ` Tim Chen [this message]
2026-02-26 22:25         ` Tim Chen
2026-02-27 13:01       ` Peter Zijlstra
2026-02-27 19:23         ` Tim Chen
2026-02-28  7:35           ` Chen, Yu C
2026-03-02 16:43             ` Peter Zijlstra
2026-03-03  6:31               ` Zhang Rui
2026-03-03  6:39                 ` Chen, Yu C
2026-03-03  8:44                 ` Peter Zijlstra
2026-02-27 11:56     ` Peter Zijlstra
2026-02-26 10:49 ` [RFC][PATCH 6/6] x86/resctrl: Fix SNC detection Peter Zijlstra
2026-02-26 19:42   ` Luck, Tony
2026-02-26 20:47     ` Luck, Tony
2026-02-27  9:26       ` Peter Zijlstra
2026-02-26 19:16 ` [RFC][PATCH 0/6] x86/topo: SNC Divination Luck, Tony
2026-03-02 18:21 ` Kyle Meyer

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=641cb6457fcbb6509351ecb45bdff300540f9f55.camel@linux.intel.com \
    --to=tim.c.chen@linux.intel.com \
    --cc=brgerst@gmail.com \
    --cc=hpa@zytor.com \
    --cc=kprateek.nayak@amd.com \
    --cc=kyle.meyer@hpe.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=patryk.wlazlyn@linux.intel.com \
    --cc=peterz@infradead.org \
    --cc=rafael.j.wysocki@intel.com \
    --cc=russ.anderson@hpe.com \
    --cc=tglx@kernel.org \
    --cc=tony.luck@intel.com \
    --cc=vinicius.gomes@intel.com \
    --cc=x86@kernel.org \
    --cc=yu.c.chen@intel.com \
    --cc=zhao1.liu@intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.