From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E55B7313E31 for ; Fri, 27 Feb 2026 11:56:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.50.34 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772193380; cv=none; b=o+jRaNT7mgpx6Xm1qcOFP9nbhOxaFDJpV9uRGso+nrA6pJpnE2d0xKv3qxzyXBaCHJXUUEgnpMkNUYeDjuSGDKMIdppqbdiOBdStmV/C3HGjAA6f2mQc8l6ObYUZDl3VkODuf1PIOy5F/vzgaRQ8yJJz/qIx+YFiKgKkO94ziow= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772193380; c=relaxed/simple; bh=MQNv/F1etgGLbscSaGAGejcwFu4CwSKT9HX2I+LoJV8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=WD353Y4U1OPkEtmomeXyQLFdcmZg1up6Glxz1ta/KfN0WyXFadlZTnCYQclWts5l4YWkVImR10u6gwrn7P7xrYhbpcjl/hnJ471f6dZXbC9+W5fjpyC4m604+0LAMvEB5uJnS42+sgpVovyyeRVdCP5kA7UYbektqJPD8bdaOn8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=none smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=tNGtL9t7; arc=none smtp.client-ip=90.155.50.34 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="tNGtL9t7" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Sender:Reply-To:Content-ID:Content-Description; bh=5+CuSJ8onxc4Rxc2S8P9KFv+XUFO3dYOQfdNV8XOS8E=; b=tNGtL9t7W6EOUO0/rtsMXUTLOb NyZDOcEPvo5Kb1AbfFV3bI5OJNL2/x2CwKX/APDErdOAtlMrxAtNaO+V+6I9YJFqQkef9EkIt8WYS UlQ1NqbYDf2piRI5q4NDfPqsMDSe1H7HLCSJorh5HUDSyn58Y4hCNOXrUlySvT/S6DgDmAE40x6UU OQxvxsAgkFWCfrqvDWOY30HPrZOiZPUUiZJVZ2b6hPqjLx8qy6r+GGNaRfD8eswWCSiQZ/zwfeEZu vBTNLoFjtkVKfHXgv4qhTO1jnpIEwhZDB8AR2s30Vm48mCXb6vOM4mv9Ah0myy5qf6uzJHIqganwU Xda+OAsw==; Received: from 77-249-17-252.cable.dynamic.v4.ziggo.nl ([77.249.17.252] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.98.2 #2 (Red Hat Linux)) id 1vvwS1-00000004VcI-0eCS; Fri, 27 Feb 2026 11:56:09 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id B1122301185; Fri, 27 Feb 2026 12:56:07 +0100 (CET) Date: Fri, 27 Feb 2026 12:56:07 +0100 From: Peter Zijlstra To: "Chen, Yu C" Cc: linux-kernel@vger.kernel.org, tim.c.chen@linux.intel.com, 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 Message-ID: <20260227115607.GG606826@noisy.programming.kicks-ass.net> References: <20260226104909.675623579@infradead.org> <20260226105052.737712686@infradead.org> <334d4edb-b8f4-41fb-aa16-6cb7abeaa21d@intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <334d4edb-b8f4-41fb-aa16-6cb7abeaa21d@intel.com> On Fri, Feb 27, 2026 at 01:07:40AM +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? Yes, give a BIOS guy enough bong-hits and this can be. That said (and knock on wood), I've so far never seen this (and please people, don't take this as a challenge). > 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. Just so. The thing I worried about is getting memory only nodes iterated in between or something. But as long as the CPU enumeration happens before the 'other' crud, then the CPU node mappings should be the consecutive low numbers and it all just works.