From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752403AbdF0OVR (ORCPT ); Tue, 27 Jun 2017 10:21:17 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:46178 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752639AbdF0OVI (ORCPT ); Tue, 27 Jun 2017 10:21:08 -0400 Date: Tue, 27 Jun 2017 16:21:02 +0200 (CEST) From: Thomas Gleixner To: Suravee Suthikulpanit cc: Borislav Petkov , x86@kernel.org, linux-kernel@vger.kernel.org, leo.duran@amd.com, yazen.ghannam@amd.com, Peter Zijlstra Subject: Re: [PATCH 1/2] x86/CPU/AMD: Present package as die instead of socket In-Reply-To: Message-ID: References: <1498545653-6755-1-git-send-email-suravee.suthikulpanit@amd.com> <1498545653-6755-2-git-send-email-suravee.suthikulpanit@amd.com> <20170627104803.wlhsqhaylbeqod37@pd.tnic> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 27 Jun 2017, Suravee Suthikulpanit wrote: > On 6/27/17 17:48, Borislav Petkov wrote: > > On Tue, Jun 27, 2017 at 01:40:52AM -0500, Suravee Suthikulpanit wrote: > > > However, this is not the case on AMD family17h multi-die processor > > > platforms, which can have up to 4 dies per socket as shown in the > > > following system topology. > > > > So what exactly does that mean? A die is a package on ZN and you can have up > > to 4 packages on a physical socket? > > Yes. 4 packages (or 4 dies, or 4 NUMA nodes) in a socket. And why is this relevant at all? The kernel does not care about sockets. Sockets are electromechanical components and completely irrelevant. The kernel cares about : Threads - Single scheduling unit Cores - Contains one or more threads Packages - Contains one or more cores. The cores share L3. NUMA Node - Contains one or more Packages which share a memory controller. I'm not aware of x86 systems which have several Packages sharing a memory controller, so Package == NUMA Node (but I might be wrong here). Platform - Contains one or more Numa Nodes All the kernel is interested in is the above and the NUMA Node distance so it knows about memory access latencies. No sockets, no MCMs, that's all completely useless for the scheduler. So if the current CPUID stuff gives you the same phycial package ID for all packages in a MCM, then this needs to be fixed at the CPUID/ACPI/BIOS level and not hacked around in the kernel. The only reason why a MCM might need it's own ID is, when it contains infrastructure which is shared between the packages, but again that's irrelevant for the scheduler. That'd be only relevant to implement a driver for that shared infrastructure. Thanks, tglx