Received: by 10.223.176.46 with SMTP id f43csp2055745wra; Thu, 25 Jan 2018 04:17:06 -0800 (PST) X-Google-Smtp-Source: AH8x224rbk8ME7vq+U8LbHJfbyJZgqtFIw1zWREb3NFxQW5TP5XlYdQDkimhUo+XKo14nLXlI6B5 X-Received: by 2002:a17:902:9a97:: with SMTP id w23-v6mr11416316plp.100.1516882625943; Thu, 25 Jan 2018 04:17:05 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516882625; cv=none; d=google.com; s=arc-20160816; b=j9X0r1GRLFgf0509XPNVpGDmhBhNa0r5otsoVx4ZGNkikqFYjIZozvv2eQISVThGaO A7QltUaZB72+EVlbn+cQQRzcy2nfstaiwG6HDGbfqhhyz0rQ+jeBXe6SOGrEUEhiMmE6 fkUcLfXGS2FZizIU0Xcv2H2hkfW8v1ne0lvwaKmycOtqgYqyCHl/x4tjeMEnj21GY8Ln VpLP7YSvFBM3aOtXcPBb2uovb42y5tHqesR7nBwU+D7EQK+7dxS8XP5Ww+zfPUTbfebu DKOT+UUdI43PpNuDc9AbmvGKT7/MUg9BebN7o4Rj+WoJEeO6S1vPRJnCkdfps2K//XM8 25dQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:in-reply-to :mime-version:user-agent:date:message-id:from:cc:references:to :subject:arc-authentication-results; bh=w9GO8oInx9Eg59s2ToOUB8x/lirq/mXn18EnnQUOjmg=; b=EB7U1OfrvjVRxD5p3HDZBJZyqNgLMzkea2lFXBDgL1p6A39sf26Y2MjqmF2qMKBIpT gMmwOmBqJwgWekQBW9G0sw47/CDOzDxdjN52bnOy7LlGPDwcD45q/iRy5kalOjIxIKsd 453oW2WZX/2iC9xvHnXjFPKqLDCdGY3H/iNIWTPy1FCEN2cGiJxR37i/yGZh0+jBMdW0 lhuZZMj3quR5ox167sp+AeD9Vf8/Klq4jr/OiGp9AUla3vF0TEi40CPhAHR3f4VIWZHW GG0UUSBvYVU4aP03pTioOZxDUOl7z8rskHl8uCaU+CiMyfr//+7Hr0+KfsiBjZ8TUOk9 kdiw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e6si405166pfb.313.2018.01.25.04.16.49; Thu, 25 Jan 2018 04:17:05 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752026AbeAYMPp (ORCPT + 99 others); Thu, 25 Jan 2018 07:15:45 -0500 Received: from szxga06-in.huawei.com ([45.249.212.32]:35386 "EHLO huawei.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1751632AbeAYMPm (ORCPT ); Thu, 25 Jan 2018 07:15:42 -0500 Received: from DGGEMS406-HUB.china.huawei.com (unknown [172.30.72.59]) by Forcepoint Email with ESMTP id F2D256B89E36F; Thu, 25 Jan 2018 20:15:26 +0800 (CST) Received: from [127.0.0.1] (10.177.32.209) by DGGEMS406-HUB.china.huawei.com (10.3.19.206) with Microsoft SMTP Server id 14.3.361.1; Thu, 25 Jan 2018 20:15:23 +0800 Subject: Re: [PATCH v6 11/12] arm64: topology: enable ACPI/PPTT based CPU topology To: Jeremy Linton , References: <20180113005920.28658-1-jeremy.linton@arm.com> <20180113005920.28658-12-jeremy.linton@arm.com> CC: , , , , , , , , , , , , , , , , , , , , Juri Lelli From: Xiongfeng Wang Message-ID: <928cb0c9-1d7a-3d0c-0538-a8bb0e2a86b1@huawei.com> Date: Thu, 25 Jan 2018 20:15:21 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20180113005920.28658-12-jeremy.linton@arm.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.177.32.209] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Jeremy, I have tested the patch with the newest UEFI. It prints the below error: [ 4.017371] BUG: arch topology borken [ 4.021069] BUG: arch topology borken [ 4.024764] BUG: arch topology borken [ 4.028460] BUG: arch topology borken [ 4.032153] BUG: arch topology borken [ 4.035849] BUG: arch topology borken [ 4.039543] BUG: arch topology borken [ 4.043239] BUG: arch topology borken [ 4.046932] BUG: arch topology borken [ 4.050629] BUG: arch topology borken [ 4.054322] BUG: arch topology borken I checked the code and found that the newest UEFI set PPTT physical_package_flag on a physical package node and the NUMA domain (SRAT domains) starts from the layer of DIE. (The topology of our board is core->cluster->die->package). When the kernel starts to build sched_domain, the multi-core sched_domain contains all the cores within a package, and the lowest NUMA sched_domain contains all the cores within a die. But the kernel requires that the multi-core sched_domain should be a subset of the lowest NUMA sched_domain, so the BUG info is printed. If we modify the UEFI to make NUMA sched_domain start from the layer of package, then all the topology information within the package will be discarded. I think we need to build the multi-core sched_domain using the cores within the cluster instead of the cores within the package. I think that's what 'multi-core' means. Multi cores form a cluster. I guess. If we build the multi-core sched_domain using the cores within a cluster, I think we need to add fields in struct cpu_topology to record which cores are in each cluster. Thanks, Xiongfeng On 2018/1/13 8:59, Jeremy Linton wrote: > Propagate the topology information from the PPTT tree to the > cpu_topology array. We can get the thread id, core_id and > cluster_id by assuming certain levels of the PPTT tree correspond > to those concepts. The package_id is flagged in the tree and can be > found by calling find_acpi_cpu_topology_package() which terminates > its search when it finds an ACPI node flagged as the physical > package. If the tree doesn't contain enough levels to represent > all of the requested levels then the root node will be returned > for all subsequent levels. > > Cc: Juri Lelli > Signed-off-by: Jeremy Linton > --- > arch/arm64/kernel/topology.c | 46 +++++++++++++++++++++++++++++++++++++++++++- > 1 file changed, 45 insertions(+), 1 deletion(-) > > diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c > index 7b06e263fdd1..ce8ec7fd6b32 100644 > --- a/arch/arm64/kernel/topology.c > +++ b/arch/arm64/kernel/topology.c > @@ -11,6 +11,7 @@ > * for more details. > */ > > +#include > #include > #include > #include > @@ -22,6 +23,7 @@ > #include > #include > #include > +#include > #include > > #include > @@ -300,6 +302,46 @@ static void __init reset_cpu_topology(void) > } > } > > +#ifdef CONFIG_ACPI > +/* > + * Propagate the topology information of the processor_topology_node tree to the > + * cpu_topology array. > + */ > +static int __init parse_acpi_topology(void) > +{ > + bool is_threaded; > + int cpu, topology_id; > + > + is_threaded = read_cpuid_mpidr() & MPIDR_MT_BITMASK; > + > + for_each_possible_cpu(cpu) { > + topology_id = find_acpi_cpu_topology(cpu, 0); > + if (topology_id < 0) > + return topology_id; > + > + if (is_threaded) { > + cpu_topology[cpu].thread_id = topology_id; > + topology_id = find_acpi_cpu_topology(cpu, 1); > + cpu_topology[cpu].core_id = topology_id; > + topology_id = find_acpi_cpu_topology_package(cpu); > + cpu_topology[cpu].package_id = topology_id; > + } else { > + cpu_topology[cpu].thread_id = -1; > + cpu_topology[cpu].core_id = topology_id; > + topology_id = find_acpi_cpu_topology_package(cpu); > + cpu_topology[cpu].package_id = topology_id; > + } > + } > + > + return 0; > +} > + > +#else > +static inline int __init parse_acpi_topology(void) > +{ > + return -EINVAL; > +} > +#endif > > void __init init_cpu_topology(void) > { > @@ -309,6 +351,8 @@ void __init init_cpu_topology(void) > * Discard anything that was parsed if we hit an error so we > * don't use partial information. > */ > - if (of_have_populated_dt() && parse_dt_topology()) > + if ((!acpi_disabled) && parse_acpi_topology()) > + reset_cpu_topology(); > + else if (of_have_populated_dt() && parse_dt_topology()) > reset_cpu_topology(); > } >