[{"id":1768779,"web_url":"http://patchwork.ozlabs.org/comment/1768779/","msgid":"<20170914184918.20406-8-jeremy.linton@arm.com>","list_archive_url":null,"date":"2017-09-14T18:49:12","subject":"[PATCH 0/6] Support PPTT for ARM64","submitter":{"id":67035,"url":"http://patchwork.ozlabs.org/api/people/67035/","name":"Jeremy Linton","email":"jeremy.linton@arm.com"},"content":"ACPI 6.2 adds the Processor Properties Topology Table (PPTT), which is\nused to describe the processor and cache topologies. Ideally it is\nused to extend/override information provided by the hardware, but\nright now ARM64 is entirely dependent on firmware provided tables.\n\nThis patch parses the table for the cache topology and CPU topology.\nFor the latter we also add an additional topology_cod_id() macro,\nand a package_id for arm64. Initially the physical id will match\nthe cluster id, but we update users of the cluster to utilize\nthe new macro. When we enable PPTT for the arm64 the cluster/socket\nstarts to differ. Because of this we also make some dynamic decisions\nabout mapping thread/core/cod/socket to the thread/socket used by the\nscheduler.\n\nFor example on juno:\n\n[root@mammon-juno-rh topology]# lstopo-no-graphics\nMachine (7048MB)\n Package L#0\n L2 L#0 (1024KB) + Core L#0\n L1d L#0 (32KB) + L1i L#0 (32KB) + PU L#0 (P#0)\n L1d L#1 (32KB) + L1i L#1 (32KB) + PU L#1 (P#1)\n L1d L#2 (32KB) + L1i L#2 (32KB) + PU L#2 (P#2)\n L1d L#3 (32KB) + L1i L#3 (32KB) + PU L#3 (P#3)\n L2 L#1 (2048KB) + Core L#1\n L1d L#4 (32KB) + L1i L#4 (48KB) + PU L#4 (P#4)\n L1d L#5 (32KB) + L1i L#5 (48KB) + PU L#5 (P#5)\n HostBridge L#0\n PCIBridge\n PCIBridge\n PCIBridge\n PCI 1095:3132\n Block(Disk) L#0 \"sda\"\n PCIBridge\n PCI 1002:68f9\n GPU L#1 \"renderD128\"\n GPU L#2 \"card0\"\n GPU L#3 \"controlD64\"\n PCIBridge\n PCI 11ab:4380\n Net L#4 \"enp8s0\"\n\n\nJeremy Linton (6):\n ACPI/PPTT: Add Processor Properties Topology Table parsing\n ACPI: Enable PPTT support on ARM64\n drivers: base: cacheinfo: arm64: Add support for ACPI based firmware\n tables\n Topology: Add cluster on die macros and arm64 decoding\n arm64: Fixup users of topology_physical_package_id\n arm64: topology: Enable ACPI/PPTT based CPU topology.\n\n arch/arm64/Kconfig | 1 +\n arch/arm64/include/asm/topology.h | 4 +-\n arch/arm64/kernel/cacheinfo.c | 23 +-\n arch/arm64/kernel/topology.c | 76 +++++-\n drivers/acpi/Makefile | 1 +\n drivers/acpi/arm64/Kconfig | 3 +\n drivers/acpi/pptt.c | 508 ++++++++++++++++++++++++++++++++++++++\n drivers/base/cacheinfo.c | 17 +-\n drivers/clk/clk-mb86s7x.c | 2 +-\n drivers/cpufreq/arm_big_little.c | 2 +-\n drivers/firmware/psci_checker.c | 2 +-\n include/linux/cacheinfo.h | 10 +-\n include/linux/topology.h | 5 +\n 13 files changed, 634 insertions(+), 20 deletions(-)\n create mode 100644 drivers/acpi/pptt.c","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org\n\theader.b=\"BAQzv1Gg\"; dkim-atps=neutral"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xtSN92cMzz9rvt\n\tfor ;\n\tFri, 15 Sep 2017 04:53:13 +1000 (AEST)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dsZG9-0006W4-S7; Thu, 14 Sep 2017 18:53:09 +0000","from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]\n\thelo=foss.arm.com)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dsZDP-0003UR-V7 for linux-arm-kernel@lists.infradead.org;\n\tThu, 14 Sep 2017 18:50:25 +0000","from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249])\n\tby usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id A9593199B;\n\tThu, 14 Sep 2017 11:49:31 -0700 (PDT)","from beelzebub.austin.arm.com (beelzebub.austin.arm.com\n\t[10.118.12.119])\n\tby usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id\n\tD0CB33F483; Thu, 14 Sep 2017 11:49:30 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:MIME-Version:Cc:List-Subscribe:\n\tList-Help:List-Post:List-Archive:List-Unsubscribe:List-Id:References:\n\tIn-Reply-To:Message-Id:Date:Subject:To:From:Reply-To:Content-ID:\n\tContent-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc\n\t:Resent-Message-ID:List-Owner;\n\tbh=AZ/EHssVZojK399nP2UpYiiefRsGs97Bo7KWbfAbMu8=;\n\tb=BAQzv1GgusKayAELTE8Evrt/4h\n\tMHtU9yWC585DnJ15cszP8IGYdj3hv+p7KbTH+sFipE0IyNp4XbQHQqjFXbNM5nkKz1grPnEfjaWxW\n\tQP65wWqZrzALubY/FDOGr9P9xQBt+oGYJh0Qdc2uPyUiIdI6VTEFyzNgR6CmxSHzV3BURgPtwkf6u\n\tutK1TZtEM5bxt6OgRovOZusGhYjR+mKWmeG8hYYaGk6uqgFDPWiM89tYtXKLgavV3xpgznJ5XceI1\n\tpXnQQYIPNCdf/b8/WH2QTtxyfTX3WqaYQ6J3vbEuZp4YU+xUozBCLC+8VW/30/y9vcJBMTm2vg1JF\n\tI6qCqrCg==;","From":"Jeremy Linton ","To":"linux-acpi@vger.kernel.org","Subject":"[PATCH 0/6] Support PPTT for ARM64","Date":"Thu, 14 Sep 2017 13:49:12 -0500","Message-Id":"<20170914184918.20406-8-jeremy.linton@arm.com>","X-Mailer":"git-send-email 2.13.5","In-Reply-To":"<20170914184918.20406-1-jeremy.linton@arm.com>","References":"<20170914184918.20406-1-jeremy.linton@arm.com>","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20170914_115020_303606_629782A0 ","X-CRM114-Status":"UNSURE ( 8.67 )","X-CRM114-Notice":"Please train this message.","X-Spam-Score":"-6.9 (------)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-6.9 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at http://www.dnswl.org/,\n\thigh trust [217.140.101.70 listed in list.dnswl.org]\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay\n\tdomain\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"lorenzo.pieralisi@arm.com, austinwc@codeaurora.org, jhugo@codeaurora.org,\n\twill.deacon@arm.com, john.garry@huawei.com, rjw@rjwysocki.net,\n\tJeremy Linton , hanjun.guo@linaro.org,\n\tsudeep.holla@arm.com, catalin.marinas@arm.com,\n\twangxiongfeng2@huawei.com, linux-arm-kernel@lists.infradead.org","MIME-Version":"1.0","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}},{"id":1769310,"web_url":"http://patchwork.ozlabs.org/comment/1769310/","msgid":"","list_archive_url":null,"date":"2017-09-15T17:05:06","subject":"Re: [PATCH 0/6] Support PPTT for ARM64","submitter":{"id":67035,"url":"http://patchwork.ozlabs.org/api/people/67035/","name":"Jeremy Linton","email":"jeremy.linton@arm.com"},"content":"On 09/14/2017 01:49 PM, Jeremy Linton wrote:\n> ACPI 6.2 adds the Processor Properties Topology Table (PPTT), which is\n> used to describe the processor and cache topologies. Ideally it is\n> used to extend/override information provided by the hardware, but\n> right now ARM64 is entirely dependent on firmware provided tables.\n\nHi,\n\nSo there is a problem with this patch set when cache nodes are \nreferenced by cpu nodes with the intention that the resulting caches \naren't shared, even though the PPTT cache node is shared. The code uses \nthe node reference when determining if caches are shared. This means \nthat it makes a mistake and thinks that all the (say L1) caches are \nshared because they share a PPTT cache node.\n\nIts a fairly small tweak, I will re-post this set.\n\n\n\n\n> \n> This patch parses the table for the cache topology and CPU topology.\n> For the latter we also add an additional topology_cod_id() macro,\n> and a package_id for arm64. Initially the physical id will match\n> the cluster id, but we update users of the cluster to utilize\n> the new macro. When we enable PPTT for the arm64 the cluster/socket\n> starts to differ. Because of this we also make some dynamic decisions\n> about mapping thread/core/cod/socket to the thread/socket used by the\n> scheduler.\n> \n> For example on juno:\n> \n> [root@mammon-juno-rh topology]# lstopo-no-graphics\n> Machine (7048MB)\n> Package L#0\n> L2 L#0 (1024KB) + Core L#0\n> L1d L#0 (32KB) + L1i L#0 (32KB) + PU L#0 (P#0)\n> L1d L#1 (32KB) + L1i L#1 (32KB) + PU L#1 (P#1)\n> L1d L#2 (32KB) + L1i L#2 (32KB) + PU L#2 (P#2)\n> L1d L#3 (32KB) + L1i L#3 (32KB) + PU L#3 (P#3)\n> L2 L#1 (2048KB) + Core L#1\n> L1d L#4 (32KB) + L1i L#4 (48KB) + PU L#4 (P#4)\n> L1d L#5 (32KB) + L1i L#5 (48KB) + PU L#5 (P#5)\n> HostBridge L#0\n> PCIBridge\n> PCIBridge\n> PCIBridge\n> PCI 1095:3132\n> Block(Disk) L#0 \"sda\"\n> PCIBridge\n> PCI 1002:68f9\n> GPU L#1 \"renderD128\"\n> GPU L#2 \"card0\"\n> GPU L#3 \"controlD64\"\n> PCIBridge\n> PCI 11ab:4380\n> Net L#4 \"enp8s0\"\n> \n> \n> Jeremy Linton (6):\n> ACPI/PPTT: Add Processor Properties Topology Table parsing\n> ACPI: Enable PPTT support on ARM64\n> drivers: base: cacheinfo: arm64: Add support for ACPI based firmware\n> tables\n> Topology: Add cluster on die macros and arm64 decoding\n> arm64: Fixup users of topology_physical_package_id\n> arm64: topology: Enable ACPI/PPTT based CPU topology.\n> \n> arch/arm64/Kconfig | 1 +\n> arch/arm64/include/asm/topology.h | 4 +-\n> arch/arm64/kernel/cacheinfo.c | 23 +-\n> arch/arm64/kernel/topology.c | 76 +++++-\n> drivers/acpi/Makefile | 1 +\n> drivers/acpi/arm64/Kconfig | 3 +\n> drivers/acpi/pptt.c | 508 ++++++++++++++++++++++++++++++++++++++\n> drivers/base/cacheinfo.c | 17 +-\n> drivers/clk/clk-mb86s7x.c | 2 +-\n> drivers/cpufreq/arm_big_little.c | 2 +-\n> drivers/firmware/psci_checker.c | 2 +-\n> include/linux/cacheinfo.h | 10 +-\n> include/linux/topology.h | 5 +\n> 13 files changed, 634 insertions(+), 20 deletions(-)\n> create mode 100644 drivers/acpi/pptt.c\n>","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org\n\theader.b=\"EM+Sikyu\"; dkim-atps=neutral"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xv1xY10Dvz9sNc\n\tfor ;\n\tSat, 16 Sep 2017 03:05:37 +1000 (AEST)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dsu3a-0001zR-2D; Fri, 15 Sep 2017 17:05:34 +0000","from foss.arm.com ([217.140.101.70])\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dsu3V-0001Su-Qv for linux-arm-kernel@lists.infradead.org;\n\tFri, 15 Sep 2017 17:05:31 +0000","from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249])\n\tby usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id C60031529;\n\tFri, 15 Sep 2017 10:05:07 -0700 (PDT)","from [192.168.229.136] (unknown [10.118.28.53])\n\tby usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id\n\tD6F803F3E1; Fri, 15 Sep 2017 10:05:06 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:Content-Type:\n\tContent-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive:\n\tList-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From:\n\tReferences:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date:\n\tResent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner;\n\tbh=rMdHFh+VhbVlTMUIoswS/ckrM+ZFma4eqKnSHsoglMg=;\n\tb=EM+SikyuiefYV0lMq2/BYt0TD\n\tQSMp6aPOz943blyBPn834k7UYNSGtYwfC1hF38DIF2FMTrQsMef0VcZrzkZjJqjZ9p68PgyvawAqK\n\tPuWlPQYvD8d+2uluXlVbF7j/wHFsX0jxiah6+0h1U3lVQ5n5X655/fJwbKM1LT+0KdztndFP0tjJe\n\t7c7gMuv3jDXA6zgwZgb+I/2cnxwmObOdhWT0fHfGK1eHBCokvMOGy7kpFHJYH+XndbJvZoy9F1Q6C\n\t1ARC/J5+9UU1zFEaQKe19HjckDOUCriP0SQ7GHg+7hiJM47WVL00Oq594pYo3yCBD3Oek4oOGRMVz\n\tF7o3UMTkA==;","Subject":"Re: [PATCH 0/6] Support PPTT for ARM64","To":"linux-acpi@vger.kernel.org","References":"<20170914184918.20406-1-jeremy.linton@arm.com>","From":"Jeremy Linton ","Message-ID":"","Date":"Fri, 15 Sep 2017 12:05:06 -0500","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.2.1","MIME-Version":"1.0","In-Reply-To":"<20170914184918.20406-1-jeremy.linton@arm.com>","Content-Language":"en-US","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20170915_100529_910002_D97CEA12 ","X-CRM114-Status":"GOOD ( 16.39 )","X-Spam-Score":"-6.9 (------)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-6.9 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at http://www.dnswl.org/,\n\thigh trust [217.140.101.70 listed in list.dnswl.org]\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay\n\tdomain\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"lorenzo.pieralisi@arm.com, austinwc@codeaurora.org, jhugo@codeaurora.org,\n\twill.deacon@arm.com, john.garry@huawei.com, rjw@rjwysocki.net,\n\thanjun.guo@linaro.org, sudeep.holla@arm.com, catalin.marinas@arm.com, \n\twangxiongfeng2@huawei.com, linux-arm-kernel@lists.infradead.org","Content-Transfer-Encoding":"7bit","Content-Type":"text/plain; charset=\"us-ascii\"; Format=\"flowed\"","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}},{"id":1769834,"web_url":"http://patchwork.ozlabs.org/comment/1769834/","msgid":"<93846e2c-df62-fda6-200a-f55bfb9955c4@huawei.com>","list_archive_url":null,"date":"2017-09-18T01:37:30","subject":"Re: [PATCH 6/6] arm64: topology: Enable ACPI/PPTT based CPU\n\ttopology.","submitter":{"id":72343,"url":"http://patchwork.ozlabs.org/api/people/72343/","name":"Xiongfeng Wang","email":"wangxiongfeng2@huawei.com"},"content":"Hi Jeremy,\n\nOn 2017/9/15 2:49, Jeremy Linton wrote:\n> Propagate the topology information from the PPTT tree to the\n> cpu_topology array. We can get the thread id, core_id and\n> cluster_id by assuming certain levels of the PPTT tree correspond\n> to those concepts. The package_id is flagged in the tree and can be\n> found by passing an arbitrary large level to setup_acpi_cpu_topology()\n> which terminates its search when it finds an ACPI node flagged\n> as the physical package. If the tree doesn't contain enough\n> levels to represent all of thread/core/cod/package then the package\n> id will be used for the missing levels.\n> \n> Since arm64 machines can have 3 distinct topology levels, and the\n> scheduler only handles sockets/threads well today, we compromise\n> by collapsing into one of three diffrent configurations. These are\n> thread/socket, thread/cluster or cluster/socket depending on whether\n> the machine has threading and multisocket, threading in a single\n> socket, or doesn't have threading.\n> \n> This code is loosely based on a combination of code from:\n> Xiongfeng Wang \n> John Garry \n> Jeffrey Hugo \n> \n> Signed-off-by: Jeremy Linton \n> ---\n> arch/arm64/kernel/topology.c | 68 +++++++++++++++++++++++++++++++++++++++++++-\n> include/linux/topology.h | 2 ++\n> 2 files changed, 69 insertions(+), 1 deletion(-)\n> \n> diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c\n> index 9147e5b6326d..8ee5cc5ba9bd 100644\n> --- a/arch/arm64/kernel/topology.c\n> +++ b/arch/arm64/kernel/topology.c\n> @@ -11,6 +11,7 @@\n> * for more details.\n> */\n> \n> +#include \n> #include \n> #include \n> #include \n> @@ -22,6 +23,7 @@\n> #include \n> #include \n> #include \n> +#include \n> #include \n> \n> #include \n> @@ -304,6 +306,68 @@ static void __init reset_cpu_topology(void)\n> \t}\n> }\n> \n> +#ifdef CONFIG_ACPI\n> +/*\n> + * Propagate the topology information of the processor_topology_node tree to the\n> + * cpu_topology array.\n> + */\n> +static int __init parse_acpi_topology(void)\n> +{\n> +\tu64 is_threaded;\n> +\tint is_multisocket;\n> +\tint cpu;\n> +\tint topology_id;\n> +\t/* set a large depth, to hit ACPI_PPTT_PHYSICAL_PACKAGE if one exists */\n> +\tconst int max_topo = 0xFF;\n> +\n> +\tis_threaded = read_cpuid_mpidr() & MPIDR_MT_BITMASK;\n> +\tis_multisocket = acpi_multisocket_count();\n> +\tif (is_multisocket < 0)\n> +\t\treturn is_multisocket;\n> +\n> +\tfor_each_possible_cpu(cpu) {\n> +\t\ttopology_id = setup_acpi_cpu_topology(cpu, 0);\n> +\t\tif (topology_id < 0)\n> +\t\t\treturn topology_id;\n> +\n> +\t\tif ((is_threaded) && (is_multisocket > 1)) {\n> +\t\t\t/* MT per core, and multiple sockets */\n> +\t\t\tcpu_topology[cpu].thread_id = topology_id;\n> +\t\t\ttopology_id = setup_acpi_cpu_topology(cpu, 1);\n> +\t\t\tcpu_topology[cpu].core_id = topology_id;\n> +\t\t\ttopology_id = setup_acpi_cpu_topology(cpu, 2);\n> +\t\t\tcpu_topology[cpu].cluster_id = topology_id;\n> +\t\t\ttopology_id = setup_acpi_cpu_topology(cpu, max_topo);\n> +\t\t\tcpu_topology[cpu].package_id = topology_id;\n> +\t\t} else if (is_threaded) {\n> +\t\t\t/* mutltiple threads, but only a single socket */\n> +\t\t\tcpu_topology[cpu].thread_id = topology_id;\n> +\t\t\ttopology_id = setup_acpi_cpu_topology(cpu, 1);\n> +\t\t\tcpu_topology[cpu].core_id = topology_id;\n> +\t\t\ttopology_id = setup_acpi_cpu_topology(cpu, 2);\n> +\t\t\tcpu_topology[cpu].cluster_id = topology_id;\n> +\t\t\tcpu_topology[cpu].package_id = topology_id;\n> +\t\t} else {\n> +\t\t\t/* no threads, clusters behave like threads */\n> +\t\t\tcpu_topology[cpu].thread_id = topology_id;\n> +\t\t\ttopology_id = setup_acpi_cpu_topology(cpu, 1);\n> +\t\t\tcpu_topology[cpu].core_id = topology_id;\n> +\t\t\tcpu_topology[cpu].cluster_id = topology_id;\n> +\t\t\ttopology_id = setup_acpi_cpu_topology(cpu, max_topo);\n> +\t\t\tcpu_topology[cpu].package_id = topology_id;\n\nI can not understand why should we consider cores in a cluster as threads. The scheduler will\nbe effected a lot by this. And the 'lstopo' may display wrong information.\n\nThanks,\nXiongfeng Wang\n\n> +\t\t}\n> +\t}\n> +\treturn 0;\n> +}\n> +\n> +#else\n> +static int __init parse_acpi_topology(void)\n> +{\n> +\t/*ACPI kernels should be built with PPTT support*/\n> +\treturn -EINVAL;\n> +}\n> +#endif\n> +\n> void __init init_cpu_topology(void)\n> {\n> \treset_cpu_topology();\n> @@ -312,6 +376,8 @@ void __init init_cpu_topology(void)\n> \t * Discard anything that was parsed if we hit an error so we\n> \t * don't use partial information.\n> \t */\n> -\tif (of_have_populated_dt() && parse_dt_topology())\n> +\tif ((!acpi_disabled) && parse_acpi_topology())\n> +\t\treset_cpu_topology();\n> +\telse if (of_have_populated_dt() && parse_dt_topology())\n> \t\treset_cpu_topology();\n> }\n> diff --git a/include/linux/topology.h b/include/linux/topology.h\n> index 4660749a7303..08bf736be7c1 100644\n> --- a/include/linux/topology.h\n> +++ b/include/linux/topology.h\n> @@ -43,6 +43,8 @@\n> \t\tif (nr_cpus_node(node))\n> \n> int arch_update_cpu_topology(void);\n> +int setup_acpi_cpu_topology(unsigned int cpu, int level);\n> +int acpi_multisocket_count(void);\n> \n> /* Conform to ACPI 2.0 SLIT distance definitions */\n> #define LOCAL_DISTANCE\t\t10\n>","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org\n\theader.b=\"ZpJoLkXL\"; dkim-atps=neutral"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xwTDY0TXLz9s7G\n\tfor ;\n\tMon, 18 Sep 2017 11:38:37 +1000 (AEST)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dtl18-0002Os-9v; Mon, 18 Sep 2017 01:38:34 +0000","from szxga05-in.huawei.com ([45.249.212.191])\n\tby bombadil.infradead.org with esmtps (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dtl0i-0002Jr-7R for linux-arm-kernel@lists.infradead.org;\n\tMon, 18 Sep 2017 01:38:10 +0000","from 172.30.72.58 (EHLO DGGEMS404-HUB.china.huawei.com)\n\t([172.30.72.58])\n\tby dggrg05-dlp.huawei.com (MOS 4.4.6-GA FastPath queued)\n\twith ESMTP id DHM50847; Mon, 18 Sep 2017 09:37:40 +0800 (CST)","from [127.0.0.1] (10.177.32.209) by DGGEMS404-HUB.china.huawei.com\n\t(10.3.19.204) with Microsoft SMTP Server id 14.3.301.0;\n\tMon, 18 Sep 2017 09:37:31 +0800"],"DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post:\n\tList-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:\n\tMessage-ID:From:References:To:Subject:Reply-To:Content-ID:Content-Description\n\t:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=eTTkAQsmALfcr29ocG7A/x2xVpXwej8raox0JRgllh4=;\n\tb=ZpJoLkXL3U4SJO\n\tPK6o6hSpaNyJyhSKIL041XhkIVSQAA80qDR7wpyxRZQeE0IQZbtQDPSd7MWYvhK4iRvbOPzWvsQ7H\n\tzHf/YOI11rL5q5Yfxt9xB3aLRuBiJDLJjc4jxXfli0xF4Gvb8cxJgxd6bIg0Xu+SaUZ0o7BKrwPyp\n\tr0pN2eIPGETYR/FMw7CcA0h5jYa182amJRwheTCKCy8ZG6hDTB1dDNIXupCbtQH/Qp7KYUXwinEPN\n\tN+ga2qRfuHbGl/SpIHVlORzyge6y4vHmVUq00dL64SOO+JZ3kiuUPbUsl0MusmK9o01GOp/EDFjM/\n\t/1PtmhrhVKc7upP5z3Uw==;","Subject":"Re: [PATCH 6/6] arm64: topology: Enable ACPI/PPTT based CPU\n\ttopology.","To":"Jeremy Linton , ","References":"<20170914184918.20406-1-jeremy.linton@arm.com>\n\t<20170914184918.20406-7-jeremy.linton@arm.com>","From":"Xiongfeng Wang ","Message-ID":"<93846e2c-df62-fda6-200a-f55bfb9955c4@huawei.com>","Date":"Mon, 18 Sep 2017 09:37:30 +0800","User-Agent":"Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101\n\tThunderbird/45.2.0","MIME-Version":"1.0","In-Reply-To":"<20170914184918.20406-7-jeremy.linton@arm.com>","X-Originating-IP":"[10.177.32.209]","X-CFilter-Loop":"Reflected","X-Mirapoint-Virus-RAPID-Raw":"score=unknown(0),\n\trefid=str=0001.0A020205.59BF2366.0009, ss=1, re=0.000, recu=0.000,\n\treip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0,\n\tso=2014-11-16 11:51:01, dmn=2013-03-21 17:37:32","X-Mirapoint-Loop-Id":"8b6f4713633aacf6c106bb7e1b3e956f","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20170917_183808_770086_E1A12A9A ","X-CRM114-Status":"GOOD ( 21.81 )","X-Spam-Score":"-1.9 (-)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-1.9 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay\n\tdomain\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"lorenzo.pieralisi@arm.com, austinwc@codeaurora.org, jhugo@codeaurora.org,\n\twill.deacon@arm.com, john.garry@huawei.com, rjw@rjwysocki.net,\n\thanjun.guo@linaro.org, sudeep.holla@arm.com, catalin.marinas@arm.com, \n\tlinux-arm-kernel@lists.infradead.org","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}},{"id":1769837,"web_url":"http://patchwork.ozlabs.org/comment/1769837/","msgid":"","list_archive_url":null,"date":"2017-09-18T01:50:27","subject":"Re: [PATCH 4/6] Topology: Add cluster on die macros and arm64\n\tdecoding","submitter":{"id":72343,"url":"http://patchwork.ozlabs.org/api/people/72343/","name":"Xiongfeng Wang","email":"wangxiongfeng2@huawei.com"},"content":"Hi Jeremy,\n\nOn 2017/9/15 2:49, Jeremy Linton wrote:\n> Many modern machines have cluster on die (COD) non-uniformity\n> as well as the traditional multi-socket architectures. Reusing\n> the multi-socket or NUMA on die concepts for these (as arm64 does)\n> breaks down when presented with actual multi-socket/COD machines.\n> Similar, problems are also visible on some x86 machines so it\n> seems appropriate to start abstracting and making these topologies\n> visible.\n> \n> To start, a topology_cod_id() macro is added which defaults to returning\n> the same information as topology_physical_package_id(). Moving forward\n> we can start to spit out the differences.\n> \n> For arm64, an additional package_id is added to the cpu_topology array.\n> Initially this will be equal to the cluster_id as well.\n> \n> Signed-off-by: Jeremy Linton \n> ---\n> arch/arm64/include/asm/topology.h | 4 +++-\n> arch/arm64/kernel/topology.c | 8 ++++++--\n> include/linux/topology.h | 3 +++\n> 3 files changed, 12 insertions(+), 3 deletions(-)\n> \n> diff --git a/arch/arm64/include/asm/topology.h b/arch/arm64/include/asm/topology.h\n> index 8b57339823e9..bd7517960d39 100644\n> --- a/arch/arm64/include/asm/topology.h\n> +++ b/arch/arm64/include/asm/topology.h\n> @@ -7,13 +7,15 @@ struct cpu_topology {\n> \tint thread_id;\n> \tint core_id;\n> \tint cluster_id;\n> +\tint package_id;\n> \tcpumask_t thread_sibling;\n> \tcpumask_t core_sibling;\n> };\n\n'core_sibling' will be updated by 'update_siblings_masks()' to represent cores in a cluster;\nCan we add a cpumask_t field to represent cores in a package? So that 'lstopo' can use this\ncpumask_t to display the right information.\n\nThanks,\nXiongfeng Wang\n\n> \n> extern struct cpu_topology cpu_topology[NR_CPUS];\n> \n> -#define topology_physical_package_id(cpu)\t(cpu_topology[cpu].cluster_id)\n> +#define topology_physical_package_id(cpu)\t(cpu_topology[cpu].package_id)\n> +#define topology_cod_id(cpu)\t\t(cpu_topology[cpu].cluster_id)\n> #define topology_core_id(cpu)\t\t(cpu_topology[cpu].core_id)\n> #define topology_core_cpumask(cpu)\t(&cpu_topology[cpu].core_sibling)\n> #define topology_sibling_cpumask(cpu)\t(&cpu_topology[cpu].thread_sibling)\n> diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c\n> index 8d48b233e6ce..9147e5b6326d 100644\n> --- a/arch/arm64/kernel/topology.c\n> +++ b/arch/arm64/kernel/topology.c\n> @@ -67,6 +67,8 @@ static int __init parse_core(struct device_node *core, int cluster_id,\n> \t\t\tleaf = false;\n> \t\t\tcpu = get_cpu_for_node(t);\n> \t\t\tif (cpu >= 0) {\n> +\t\t\t\t/* maintain DT cluster == package behavior */\n> +\t\t\t\tcpu_topology[cpu].package_id = cluster_id;\n> \t\t\t\tcpu_topology[cpu].cluster_id = cluster_id;\n> \t\t\t\tcpu_topology[cpu].core_id = core_id;\n> \t\t\t\tcpu_topology[cpu].thread_id = i;\n> @@ -88,7 +90,7 @@ static int __init parse_core(struct device_node *core, int cluster_id,\n> \t\t\t core);\n> \t\t\treturn -EINVAL;\n> \t\t}\n> -\n> +\t\tcpu_topology[cpu].package_id = cluster_id;\n> \t\tcpu_topology[cpu].cluster_id = cluster_id;\n> \t\tcpu_topology[cpu].core_id = core_id;\n> \t} else if (leaf) {\n> @@ -228,7 +230,7 @@ static void update_siblings_masks(unsigned int cpuid)\n> \tfor_each_possible_cpu(cpu) {\n> \t\tcpu_topo = &cpu_topology[cpu];\n> \n> -\t\tif (cpuid_topo->cluster_id != cpu_topo->cluster_id)\n> +\t\tif (cpuid_topo->package_id != cpu_topo->package_id)\n> \t\t\tcontinue;\n> \n> \t\tcpumask_set_cpu(cpuid, &cpu_topo->core_sibling);\n> @@ -273,6 +275,7 @@ void store_cpu_topology(unsigned int cpuid)\n> \t\t\t\t\t MPIDR_AFFINITY_LEVEL(mpidr, 2) << 8 |\n> \t\t\t\t\t MPIDR_AFFINITY_LEVEL(mpidr, 3) << 16;\n> \t}\n> +\tcpuid_topo->package_id = cpuid_topo->cluster_id;\n> \n> \tpr_debug(\"CPU%u: cluster %d core %d thread %d mpidr %#016llx\\n\",\n> \t\t cpuid, cpuid_topo->cluster_id, cpuid_topo->core_id,\n> @@ -292,6 +295,7 @@ static void __init reset_cpu_topology(void)\n> \t\tcpu_topo->thread_id = -1;\n> \t\tcpu_topo->core_id = 0;\n> \t\tcpu_topo->cluster_id = -1;\n> +\t\tcpu_topo->package_id = -1;\n> \n> \t\tcpumask_clear(&cpu_topo->core_sibling);\n> \t\tcpumask_set_cpu(cpu, &cpu_topo->core_sibling);\n> diff --git a/include/linux/topology.h b/include/linux/topology.h\n> index cb0775e1ee4b..4660749a7303 100644\n> --- a/include/linux/topology.h\n> +++ b/include/linux/topology.h\n> @@ -184,6 +184,9 @@ static inline int cpu_to_mem(int cpu)\n> #ifndef topology_physical_package_id\n> #define topology_physical_package_id(cpu)\t((void)(cpu), -1)\n> #endif\n> +#ifndef topology_cod_id\t\t\t\t/* cluster on die */\n> +#define topology_cod_id(cpu)\t\t\ttopology_physical_package_id(cpu)\n> +#endif\n> #ifndef topology_core_id\n> #define topology_core_id(cpu)\t\t\t((void)(cpu), 0)\n> #endif\n>","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org\n\theader.b=\"PEUfHaxD\"; dkim-atps=neutral"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xwTW33lG1z9s7c\n\tfor ;\n\tMon, 18 Sep 2017 11:51:11 +1000 (AEST)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dtlDH-0001mb-W8; Mon, 18 Sep 2017 01:51:08 +0000","from szxga04-in.huawei.com ([45.249.212.190])\n\tby bombadil.infradead.org with esmtps (Exim 4.87 #1 (Red Hat Linux))\n\tid 1dtlDC-0001fo-WF for linux-arm-kernel@lists.infradead.org;\n\tMon, 18 Sep 2017 01:51:05 +0000","from 172.30.72.60 (EHLO DGGEMS404-HUB.china.huawei.com)\n\t([172.30.72.60])\n\tby dggrg04-dlp.huawei.com (MOS 4.4.6-GA FastPath queued)\n\twith ESMTP id DHK52714; Mon, 18 Sep 2017 09:50:36 +0800 (CST)","from [127.0.0.1] (10.177.32.209) by DGGEMS404-HUB.china.huawei.com\n\t(10.3.19.204) with Microsoft SMTP Server id 14.3.301.0;\n\tMon, 18 Sep 2017 09:50:28 +0800"],"DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post:\n\tList-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:\n\tMessage-ID:From:References:To:Subject:Reply-To:Content-ID:Content-Description\n\t:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=5kEM18NwnlmzKawJikJAkU5ye2XNwGKdSRcO3Rl/d+E=;\n\tb=PEUfHaxDidFVsE\n\tbVQ2yO7UtFUhshMkuNTvDOQ6jyB/l/v9U89Jcg10dxy6rC4tNj3C3lGnOFKgAg5xbBrpZeR3uGIve\n\tc2nlxDGYh8q82a1P0IB0rV+zHIv1gcLW/fp7j7nYi+qJ5O6uEfzg5nwIcQ1bAYbcVBh2Eo9M0+Anp\n\txhkl5928rcuTIznAfshzKgGde7+R8LIyrlGDAaXsx05H3jpVrYlc8R2BakQq3ZrK4ddta79kf1hnO\n\tXamRDD9CWYchsxEWDCUQiW3qhGhxef0MN5J7w9VwYuh7lTr6Y+/PNmp6PU7ycjwcfsY+r39gFfEII\n\ttZTSn4jJ1c/lORVHfXxQ==;","Subject":"Re: [PATCH 4/6] Topology: Add cluster on die macros and arm64\n\tdecoding","To":"Jeremy Linton , ","References":"<20170914184918.20406-1-jeremy.linton@arm.com>\n\t<20170914184918.20406-5-jeremy.linton@arm.com>","From":"Xiongfeng Wang ","Message-ID":"","Date":"Mon, 18 Sep 2017 09:50:27 +0800","User-Agent":"Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101\n\tThunderbird/45.2.0","MIME-Version":"1.0","In-Reply-To":"<20170914184918.20406-5-jeremy.linton@arm.com>","X-Originating-IP":"[10.177.32.209]","X-CFilter-Loop":"Reflected","X-Mirapoint-Virus-RAPID-Raw":"score=unknown(0),\n\trefid=str=0001.0A020201.59BF266D.00CA, ss=1, re=0.000, recu=0.000,\n\treip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0,\n\tso=2014-11-16 11:51:01, dmn=2013-03-21 17:37:32","X-Mirapoint-Loop-Id":"9109f2eb89249b7cc215fdd612b7291c","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20170917_185103_590307_4F4D06F3 ","X-CRM114-Status":"GOOD ( 15.86 )","X-Spam-Score":"-1.9 (-)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-1.9 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay\n\tdomain\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"lorenzo.pieralisi@arm.com, austinwc@codeaurora.org, jhugo@codeaurora.org,\n\twill.deacon@arm.com, john.garry@huawei.com, rjw@rjwysocki.net,\n\thanjun.guo@linaro.org, sudeep.holla@arm.com, catalin.marinas@arm.com, \n\tlinux-arm-kernel@lists.infradead.org","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}},{"id":1770425,"web_url":"http://patchwork.ozlabs.org/comment/1770425/","msgid":"<8e145e4b-e1d2-cb15-2cf9-cace5fed524f@arm.com>","list_archive_url":null,"date":"2017-09-18T18:54:26","subject":"Re: [PATCH 4/6] Topology: Add cluster on die macros and arm64\n\tdecoding","submitter":{"id":67035,"url":"http://patchwork.ozlabs.org/api/people/67035/","name":"Jeremy Linton","email":"jeremy.linton@arm.com"},"content":"Hi,\n\n\nOn 09/17/2017 08:50 PM, Xiongfeng Wang wrote:\n> Hi Jeremy,\n> \n> On 2017/9/15 2:49, Jeremy Linton wrote:\n>> Many modern machines have cluster on die (COD) non-uniformity\n>> as well as the traditional multi-socket architectures. Reusing\n>> the multi-socket or NUMA on die concepts for these (as arm64 does)\n>> breaks down when presented with actual multi-socket/COD machines.\n>> Similar, problems are also visible on some x86 machines so it\n>> seems appropriate to start abstracting and making these topologies\n>> visible.\n>>\n>> To start, a topology_cod_id() macro is added which defaults to returning\n>> the same information as topology_physical_package_id(). Moving forward\n>> we can start to spit out the differences.\n>>\n>> For arm64, an additional package_id is added to the cpu_topology array.\n>> Initially this will be equal to the cluster_id as well.\n>>\n>> Signed-off-by: Jeremy Linton \n>> ---\n>> arch/arm64/include/asm/topology.h | 4 +++-\n>> arch/arm64/kernel/topology.c | 8 ++++++--\n>> include/linux/topology.h | 3 +++\n>> 3 files changed, 12 insertions(+), 3 deletions(-)\n>>\n>> diff --git a/arch/arm64/include/asm/topology.h b/arch/arm64/include/asm/topology.h\n>> index 8b57339823e9..bd7517960d39 100644\n>> --- a/arch/arm64/include/asm/topology.h\n>> +++ b/arch/arm64/include/asm/topology.h\n>> @@ -7,13 +7,15 @@ struct cpu_topology {\n>> \tint thread_id;\n>> \tint core_id;\n>> \tint cluster_id;\n>> +\tint package_id;\n>> \tcpumask_t thread_sibling;\n>> \tcpumask_t core_sibling;\n>> };\n> \n> 'core_sibling' will be updated by 'update_siblings_masks()' to represent cores in a cluster;\n> Can we add a cpumask_t field to represent cores in a package? So that 'lstopo' can use this\n> cpumask_t to display the right information.\n\nSo, the change below modifies update_siblings_mask() to utilize the \npackage_id. Per the ABI the ..cpuX/topology/physical_package_id is \nshared between the core_siblings/core_siblings_list. What \nphysical_package_id means can vary per architecture, but the siblings \nlist needs to be the cores with the same phyiscal_package (AFAIK, feel \nfree to correct my understanding). That rule should be enforced by this \npatch set.\n\nI suspect if your running these patches, and the lstopo output looks \nstrange its because your on a machine where the thread_id has been \nassigned the cluster_id in the later patch set.\n\n\n> \n> Thanks,\n> Xiongfeng Wang\n> \n>> \n>> extern struct cpu_topology cpu_topology[NR_CPUS];\n>> \n>> -#define topology_physical_package_id(cpu)\t(cpu_topology[cpu].cluster_id)\n>> +#define topology_physical_package_id(cpu)\t(cpu_topology[cpu].package_id)\n>> +#define topology_cod_id(cpu)\t\t(cpu_topology[cpu].cluster_id)\n>> #define topology_core_id(cpu)\t\t(cpu_topology[cpu].core_id)\n>> #define topology_core_cpumask(cpu)\t(&cpu_topology[cpu].core_sibling)\n>> #define topology_sibling_cpumask(cpu)\t(&cpu_topology[cpu].thread_sibling)\n>> diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c\n>> index 8d48b233e6ce..9147e5b6326d 100644\n>> --- a/arch/arm64/kernel/topology.c\n>> +++ b/arch/arm64/kernel/topology.c\n>> @@ -67,6 +67,8 @@ static int __init parse_core(struct device_node *core, int cluster_id,\n>> \t\t\tleaf = false;\n>> \t\t\tcpu = get_cpu_for_node(t);\n>> \t\t\tif (cpu >= 0) {\n>> +\t\t\t\t/* maintain DT cluster == package behavior */\n>> +\t\t\t\tcpu_topology[cpu].package_id = cluster_id;\n>> \t\t\t\tcpu_topology[cpu].cluster_id = cluster_id;\n>> \t\t\t\tcpu_topology[cpu].core_id = core_id;\n>> \t\t\t\tcpu_topology[cpu].thread_id = i;\n>> @@ -88,7 +90,7 @@ static int __init parse_core(struct device_node *core, int cluster_id,\n>> \t\t\t core);\n>> \t\t\treturn -EINVAL;\n>> \t\t}\n>> -\n>> +\t\tcpu_topology[cpu].package_id = cluster_id;\n>> \t\tcpu_topology[cpu].cluster_id = cluster_id;\n>> \t\tcpu_topology[cpu].core_id = core_id;\n>> \t} else if (leaf) {\n>> @@ -228,7 +230,7 @@ static void update_siblings_masks(unsigned int cpuid)\n>> \tfor_each_possible_cpu(cpu) {\n>> \t\tcpu_topo = &cpu_topology[cpu];\n>> \n>> -\t\tif (cpuid_topo->cluster_id != cpu_topo->cluster_id)\n>> +\t\tif (cpuid_topo->package_id != cpu_topo->package_id)\n\n(note here that core_siblings now reflect the package_id rather than the \ncluster_id. This only matters if cluster_id!=package_id).\n\n>> \t\t\tcontinue;\n>> \n>> \t\tcpumask_set_cpu(cpuid, &cpu_topo->core_sibling);\n>> @@ -273,6 +275,7 @@ void store_cpu_topology(unsigned int cpuid)\n>> \t\t\t\t\t MPIDR_AFFINITY_LEVEL(mpidr, 2) << 8 |\n>> \t\t\t\t\t MPIDR_AFFINITY_LEVEL(mpidr, 3) << 16;\n>> \t}\n>> +\tcpuid_topo->package_id = cpuid_topo->cluster_id;\n>> \n>> \tpr_debug(\"CPU%u: cluster %d core %d thread %d mpidr %#016llx\\n\",\n>> \t\t cpuid, cpuid_topo->cluster_id, cpuid_topo->core_id,\n>> @@ -292,6 +295,7 @@ static void __init reset_cpu_topology(void)\n>> \t\tcpu_topo->thread_id = -1;\n>> \t\tcpu_topo->core_id = 0;\n>> \t\tcpu_topo->cluster_id = -1;\n>> +\t\tcpu_topo->package_id = -1;\n>> \n>> \t\tcpumask_clear(&cpu_topo->core_sibling);\n>> \t\tcpumask_set_cpu(cpu, &cpu_topo->core_sibling);\n>> diff --git a/include/linux/topology.h b/include/linux/topology.h\n>> index cb0775e1ee4b..4660749a7303 100644\n>> --- a/include/linux/topology.h\n>> +++ b/include/linux/topology.h\n>> @@ -184,6 +184,9 @@ static inline int cpu_to_mem(int cpu)\n>> #ifndef topology_physical_package_id\n>> #define topology_physical_package_id(cpu)\t((void)(cpu), -1)\n>> #endif\n>> +#ifndef topology_cod_id\t\t\t\t/* cluster on die */\n>> +#define topology_cod_id(cpu)\t\t\ttopology_physical_package_id(cpu)\n>> +#endif\n>> #ifndef topology_core_id\n>> #define topology_core_id(cpu)\t\t\t((void)(cpu), 0)\n>> #endif\n>>\n> \n> \n> _______________________________________________\n> linux-arm-kernel mailing list\n> linux-arm-kernel@lists.infradead.org\n> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel\n>","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org\n\theader.b=\"oUywvlni\"; dkim-atps=neutral"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xwwDN0MFzz9s4s\n\tfor ;\n\tTue, 19 Sep 2017 04:55:00 +1000 (AEST)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1du1C5-0007YY-0s; Mon, 18 Sep 2017 18:54:57 +0000","from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]\n\thelo=foss.arm.com)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1du1C0-0007TZ-Hl for linux-arm-kernel@lists.infradead.org;\n\tMon, 18 Sep 2017 18:54:54 +0000","from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249])\n\tby usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 5A0D81435;\n\tMon, 18 Sep 2017 11:54:30 -0700 (PDT)","from [192.168.229.136] (u201426.usa.arm.com [10.118.110.55])\n\tby usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id\n\t64E493F483; Mon, 18 Sep 2017 11:54:29 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:Content-Type:\n\tContent-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive:\n\tList-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From:\n\tReferences:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date:\n\tResent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner;\n\tbh=S6wu0V7t6qvp/4hWZIX60EmStA5tFJBj4ijZnfOxUrI=;\n\tb=oUywvlni0Hx40CPGKwkY92gGS\n\tzqlZnszqaCZFhF7ei82PFitLKHi83WQYZkycYWMsQUtve04Vk/7P0cCx/aBT9rN13JSSJj6MmwYvb\n\tZ2FOa0cin1RAYikNvl6hLoYheUuZds3YqNUzpdcvCLp/2mJMByzt7c8XL7JYRrW9LySucGSa1ELoO\n\tyjNcb6+1rIItXGZF8K0xUK9oGMjaD86fsfH9xlvDm3swC6Ep+SSk1ExARS+zMzIBuB3/rSCyH758c\n\taC1eAQlgwLqc1y3uwa7KmqeaIE78OMxzN8Lc8qguVOkzoDr2tXOsZfHZYdO3GTu0yVLnlfmuj4yr5\n\tr10EZfKug==;","Subject":"Re: [PATCH 4/6] Topology: Add cluster on die macros and arm64\n\tdecoding","To":"Xiongfeng Wang , linux-acpi@vger.kernel.org","References":"<20170914184918.20406-1-jeremy.linton@arm.com>\n\t<20170914184918.20406-5-jeremy.linton@arm.com>\n\t","From":"Jeremy Linton ","Message-ID":"<8e145e4b-e1d2-cb15-2cf9-cace5fed524f@arm.com>","Date":"Mon, 18 Sep 2017 13:54:26 -0500","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.2.1","MIME-Version":"1.0","In-Reply-To":"","Content-Language":"en-US","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20170918_115452_611616_06766396 ","X-CRM114-Status":"GOOD ( 18.54 )","X-Spam-Score":"-6.9 (------)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-6.9 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at http://www.dnswl.org/,\n\thigh trust [217.140.101.70 listed in list.dnswl.org]\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay\n\tdomain\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"lorenzo.pieralisi@arm.com, austinwc@codeaurora.org, jhugo@codeaurora.org,\n\trjw@rjwysocki.net, john.garry@huawei.com, will.deacon@arm.com,\n\thanjun.guo@linaro.org, sudeep.holla@arm.com, catalin.marinas@arm.com, \n\tlinux-arm-kernel@lists.infradead.org","Content-Transfer-Encoding":"7bit","Content-Type":"text/plain; charset=\"us-ascii\"; Format=\"flowed\"","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}},{"id":1770429,"web_url":"http://patchwork.ozlabs.org/comment/1770429/","msgid":"<9a8e13d6-4b5e-cfa2-44c4-4d79aca94800@arm.com>","list_archive_url":null,"date":"2017-09-18T19:02:00","subject":"Re: [PATCH 6/6] arm64: topology: Enable ACPI/PPTT based CPU\n\ttopology.","submitter":{"id":67035,"url":"http://patchwork.ozlabs.org/api/people/67035/","name":"Jeremy Linton","email":"jeremy.linton@arm.com"},"content":"On 09/17/2017 08:37 PM, Xiongfeng Wang wrote:\n> Hi Jeremy,\n> \n> On 2017/9/15 2:49, Jeremy Linton wrote:\n>> Propagate the topology information from the PPTT tree to the\n>> cpu_topology array. We can get the thread id, core_id and\n>> cluster_id by assuming certain levels of the PPTT tree correspond\n>> to those concepts. The package_id is flagged in the tree and can be\n>> found by passing an arbitrary large level to setup_acpi_cpu_topology()\n>> which terminates its search when it finds an ACPI node flagged\n>> as the physical package. If the tree doesn't contain enough\n>> levels to represent all of thread/core/cod/package then the package\n>> id will be used for the missing levels.\n>>\n>> Since arm64 machines can have 3 distinct topology levels, and the\n>> scheduler only handles sockets/threads well today, we compromise\n>> by collapsing into one of three diffrent configurations. These are\n>> thread/socket, thread/cluster or cluster/socket depending on whether\n>> the machine has threading and multisocket, threading in a single\n>> socket, or doesn't have threading.\n>>\n>> This code is loosely based on a combination of code from:\n>> Xiongfeng Wang \n>> John Garry \n>> Jeffrey Hugo \n>>\n>> Signed-off-by: Jeremy Linton \n>> ---\n>> arch/arm64/kernel/topology.c | 68 +++++++++++++++++++++++++++++++++++++++++++-\n>> include/linux/topology.h | 2 ++\n>> 2 files changed, 69 insertions(+), 1 deletion(-)\n>>\n>> diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c\n>> index 9147e5b6326d..8ee5cc5ba9bd 100644\n>> --- a/arch/arm64/kernel/topology.c\n>> +++ b/arch/arm64/kernel/topology.c\n>> @@ -11,6 +11,7 @@\n>> * for more details.\n>> */\n>> \n>> +#include \n>> #include \n>> #include \n>> #include \n>> @@ -22,6 +23,7 @@\n>> #include \n>> #include \n>> #include \n>> +#include \n>> #include \n>> \n>> #include \n>> @@ -304,6 +306,68 @@ static void __init reset_cpu_topology(void)\n>> \t}\n>> }\n>> \n>> +#ifdef CONFIG_ACPI\n>> +/*\n>> + * Propagate the topology information of the processor_topology_node tree to the\n>> + * cpu_topology array.\n>> + */\n>> +static int __init parse_acpi_topology(void)\n>> +{\n>> +\tu64 is_threaded;\n>> +\tint is_multisocket;\n>> +\tint cpu;\n>> +\tint topology_id;\n>> +\t/* set a large depth, to hit ACPI_PPTT_PHYSICAL_PACKAGE if one exists */\n>> +\tconst int max_topo = 0xFF;\n>> +\n>> +\tis_threaded = read_cpuid_mpidr() & MPIDR_MT_BITMASK;\n>> +\tis_multisocket = acpi_multisocket_count();\n>> +\tif (is_multisocket < 0)\n>> +\t\treturn is_multisocket;\n>> +\n>> +\tfor_each_possible_cpu(cpu) {\n>> +\t\ttopology_id = setup_acpi_cpu_topology(cpu, 0);\n>> +\t\tif (topology_id < 0)\n>> +\t\t\treturn topology_id;\n>> +\n>> +\t\tif ((is_threaded) && (is_multisocket > 1)) {\n>> +\t\t\t/* MT per core, and multiple sockets */\n>> +\t\t\tcpu_topology[cpu].thread_id = topology_id;\n>> +\t\t\ttopology_id = setup_acpi_cpu_topology(cpu, 1);\n>> +\t\t\tcpu_topology[cpu].core_id = topology_id;\n>> +\t\t\ttopology_id = setup_acpi_cpu_topology(cpu, 2);\n>> +\t\t\tcpu_topology[cpu].cluster_id = topology_id;\n>> +\t\t\ttopology_id = setup_acpi_cpu_topology(cpu, max_topo);\n>> +\t\t\tcpu_topology[cpu].package_id = topology_id;\n>> +\t\t} else if (is_threaded) {\n>> +\t\t\t/* mutltiple threads, but only a single socket */\n>> +\t\t\tcpu_topology[cpu].thread_id = topology_id;\n>> +\t\t\ttopology_id = setup_acpi_cpu_topology(cpu, 1);\n>> +\t\t\tcpu_topology[cpu].core_id = topology_id;\n>> +\t\t\ttopology_id = setup_acpi_cpu_topology(cpu, 2);\n>> +\t\t\tcpu_topology[cpu].cluster_id = topology_id;\n>> +\t\t\tcpu_topology[cpu].package_id = topology_id;\n>> +\t\t} else {\n>> +\t\t\t/* no threads, clusters behave like threads */\n>> +\t\t\tcpu_topology[cpu].thread_id = topology_id;\n>> +\t\t\ttopology_id = setup_acpi_cpu_topology(cpu, 1);\n>> +\t\t\tcpu_topology[cpu].core_id = topology_id;\n>> +\t\t\tcpu_topology[cpu].cluster_id = topology_id;\n>> +\t\t\ttopology_id = setup_acpi_cpu_topology(cpu, max_topo);\n>> +\t\t\tcpu_topology[cpu].package_id = topology_id;\n> \n> I can not understand why should we consider cores in a cluster as threads. The scheduler will\n> be effected a lot by this. And the 'lstopo' may display wrong information.\n\nMy take, is that we shouldn't be discarding the cluster information \nbecause its extremely valuable. In many ways it seems that clustered \ncores have, at a high level, similar performance characteristics to \nthreads (AKA, cores in a cluster have high performance when sharing \ndata, but for problems with little sharing its more advantageous to \nfirst schedule those threads to differing clusters). Although, how much \naffect this has vs the MC cache priorities in the scheduler isn't \napparent to me.\n\nAnyway, lstopo doesn't currently know about anything beyond \npackage/thread, except for the book. The question is, do we want to \nmisuse the book_id to represent sockets and continue to use cluster_id \nas the physical_package_id? I don't think that is a better plan than \nwhat I've done here.\n\n\nThe bottom line, is that after having looked at the scheduler a bit, I \nsuspect that thread=cluster for machines without MT doesn't' really \nmatter much. So, the next version i'm just going to collapse this into \nwhat everyone expects socket=socket and thread=thread for ACPI users \n(which are more likely to have NUMA and multisocket at this point). The \ncluster knowledge is still somewhat visible to the scheduler via the \ncache topology.\n\n\n\n\n> \n> Thanks,\n> Xiongfeng Wang\n> \n>> +\t\t}\n>> +\t}\n>> +\treturn 0;\n>> +}\n>> +\n>> +#else\n>> +static int __init parse_acpi_topology(void)\n>> +{\n>> +\t/*ACPI kernels should be built with PPTT support*/\n>> +\treturn -EINVAL;\n>> +}\n>> +#endif\n>> +\n>> void __init init_cpu_topology(void)\n>> {\n>> \treset_cpu_topology();\n>> @@ -312,6 +376,8 @@ void __init init_cpu_topology(void)\n>> \t * Discard anything that was parsed if we hit an error so we\n>> \t * don't use partial information.\n>> \t */\n>> -\tif (of_have_populated_dt() && parse_dt_topology())\n>> +\tif ((!acpi_disabled) && parse_acpi_topology())\n>> +\t\treset_cpu_topology();\n>> +\telse if (of_have_populated_dt() && parse_dt_topology())\n>> \t\treset_cpu_topology();\n>> }\n>> diff --git a/include/linux/topology.h b/include/linux/topology.h\n>> index 4660749a7303..08bf736be7c1 100644\n>> --- a/include/linux/topology.h\n>> +++ b/include/linux/topology.h\n>> @@ -43,6 +43,8 @@\n>> \t\tif (nr_cpus_node(node))\n>> \n>> int arch_update_cpu_topology(void);\n>> +int setup_acpi_cpu_topology(unsigned int cpu, int level);\n>> +int acpi_multisocket_count(void);\n>> \n>> /* Conform to ACPI 2.0 SLIT distance definitions */\n>> #define LOCAL_DISTANCE\t\t10\n>>\n>","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org\n\theader.b=\"n4ILkki0\"; dkim-atps=neutral"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xwwP1729jz9s78\n\tfor ;\n\tTue, 19 Sep 2017 05:02:29 +1000 (AEST)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1du1JK-0003HJ-K9; Mon, 18 Sep 2017 19:02:26 +0000","from foss.arm.com ([217.140.101.70])\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1du1JG-0003E3-IL for linux-arm-kernel@lists.infradead.org;\n\tMon, 18 Sep 2017 19:02:24 +0000","from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249])\n\tby usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 4FCBA1435;\n\tMon, 18 Sep 2017 12:02:02 -0700 (PDT)","from [192.168.229.136] (u201426.usa.arm.com [10.118.110.55])\n\tby usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id\n\t558983F483; Mon, 18 Sep 2017 12:02:01 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:Content-Type:\n\tContent-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive:\n\tList-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From:\n\tReferences:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date:\n\tResent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner;\n\tbh=CdTbgcE17mPqfWBq8ufBZPoLcfjrEy3VwmlsKprdHEQ=;\n\tb=n4ILkki0WF+88RHDYUdfgCYVB\n\tkJ5Qbn+pHXXlgg3ccN+l5cN5vStz+8JdPoxbAKSnaP3d+MB1aYaz/xDow5UE8vk7kXTDYpoKfrULa\n\tNEsQjCACNHkxyw6KYdK3pGtkjEZUA977wCg0Pi/nagFRDfK0BjacS0ceCSyeo1M7wePaIZWx97N6l\n\tGfozPPurAf/kOJ2PDKjRId0a+SG7Us0d7xzGuTZD/palUMHojMIebjGsDQoeasFHw6sqGdkPN7gs2\n\tRe4+ncBWLTstYJ3TwUi9XWMSUnPDfgR+OvpXDUGs8E64ki8cXFmzMucDWbAqEU8Fu98DBf8SlJf9T\n\tTh5w/pkxA==;","Subject":"Re: [PATCH 6/6] arm64: topology: Enable ACPI/PPTT based CPU\n\ttopology.","To":"Xiongfeng Wang , linux-acpi@vger.kernel.org","References":"<20170914184918.20406-1-jeremy.linton@arm.com>\n\t<20170914184918.20406-7-jeremy.linton@arm.com>\n\t<93846e2c-df62-fda6-200a-f55bfb9955c4@huawei.com>","From":"Jeremy Linton ","Message-ID":"<9a8e13d6-4b5e-cfa2-44c4-4d79aca94800@arm.com>","Date":"Mon, 18 Sep 2017 14:02:00 -0500","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.2.1","MIME-Version":"1.0","In-Reply-To":"<93846e2c-df62-fda6-200a-f55bfb9955c4@huawei.com>","Content-Language":"en-US","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20170918_120222_706341_F8C8C2CA ","X-CRM114-Status":"GOOD ( 20.73 )","X-Spam-Score":"-6.9 (------)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-6.9 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at http://www.dnswl.org/,\n\thigh trust [217.140.101.70 listed in list.dnswl.org]\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay\n\tdomain\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"lorenzo.pieralisi@arm.com, austinwc@codeaurora.org, jhugo@codeaurora.org,\n\twill.deacon@arm.com, john.garry@huawei.com, rjw@rjwysocki.net,\n\thanjun.guo@linaro.org, sudeep.holla@arm.com, catalin.marinas@arm.com, \n\tlinux-arm-kernel@lists.infradead.org","Content-Transfer-Encoding":"7bit","Content-Type":"text/plain; charset=\"us-ascii\"; Format=\"flowed\"","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}},{"id":1770600,"web_url":"http://patchwork.ozlabs.org/comment/1770600/","msgid":"<1e41b605-371b-ee54-f251-ad58082d236e@huawei.com>","list_archive_url":null,"date":"2017-09-19T01:03:47","subject":"Re: [PATCH 4/6] Topology: Add cluster on die macros and arm64\n\tdecoding","submitter":{"id":72343,"url":"http://patchwork.ozlabs.org/api/people/72343/","name":"Xiongfeng Wang","email":"wangxiongfeng2@huawei.com"},"content":"Hi Jeremy,\n\nOn 2017/9/19 2:54, Jeremy Linton wrote:\n> Hi,\n> \n> \n> On 09/17/2017 08:50 PM, Xiongfeng Wang wrote:\n>> Hi Jeremy,\n>>\n>> On 2017/9/15 2:49, Jeremy Linton wrote:\n>>> Many modern machines have cluster on die (COD) non-uniformity\n>>> as well as the traditional multi-socket architectures. Reusing\n>>> the multi-socket or NUMA on die concepts for these (as arm64 does)\n>>> breaks down when presented with actual multi-socket/COD machines.\n>>> Similar, problems are also visible on some x86 machines so it\n>>> seems appropriate to start abstracting and making these topologies\n>>> visible.\n>>>\n>>> To start, a topology_cod_id() macro is added which defaults to returning\n>>> the same information as topology_physical_package_id(). Moving forward\n>>> we can start to spit out the differences.\n>>>\n>>> For arm64, an additional package_id is added to the cpu_topology array.\n>>> Initially this will be equal to the cluster_id as well.\n>>>\n>>> Signed-off-by: Jeremy Linton \n>>> ---\n>>> arch/arm64/include/asm/topology.h | 4 +++-\n>>> arch/arm64/kernel/topology.c | 8 ++++++--\n>>> include/linux/topology.h | 3 +++\n>>> 3 files changed, 12 insertions(+), 3 deletions(-)\n>>>\n>>> diff --git a/arch/arm64/include/asm/topology.h b/arch/arm64/include/asm/topology.h\n>>> index 8b57339823e9..bd7517960d39 100644\n>>> --- a/arch/arm64/include/asm/topology.h\n>>> +++ b/arch/arm64/include/asm/topology.h\n>>> @@ -7,13 +7,15 @@ struct cpu_topology {\n>>> int thread_id;\n>>> int core_id;\n>>> int cluster_id;\n>>> + int package_id;\n>>> cpumask_t thread_sibling;\n>>> cpumask_t core_sibling;\n>>> };\n>>\n>> 'core_sibling' will be updated by 'update_siblings_masks()' to represent cores in a cluster;\n>> Can we add a cpumask_t field to represent cores in a package? So that 'lstopo' can use this\n>> cpumask_t to display the right information.\n> \n> So, the change below modifies update_siblings_mask() to utilize the package_id. Per the ABI the ..cpuX/topology/physical_package_id is shared between the core_siblings/core_siblings_list. What physical_package_id means can vary per architecture, but the siblings list needs to be the cores with the same phyiscal_package (AFAIK, feel free to correct my understanding). That rule should be enforced by this patch set.\n> \n> I suspect if your running these patches, and the lstopo output looks strange its because your on a machine where the thread_id has been assigned the cluster_id in the later patch set.\n> \nSorry, I didn't notice your change in 'update_siblings_masks()' before, so 'core_sibling' are represent cores in a package now.\nBut we may need another cpumask_t field to represent cores in a cluster, so that the scheduler can use it to build a sched_domain\nonly with cores in one cluster.\n> \n>>\n>> Thanks,\n>> Xiongfeng Wang\n>>\n>>> extern struct cpu_topology cpu_topology[NR_CPUS];\n>>> -#define topology_physical_package_id(cpu) (cpu_topology[cpu].cluster_id)\n>>> +#define topology_physical_package_id(cpu) (cpu_topology[cpu].package_id)\n>>> +#define topology_cod_id(cpu) (cpu_topology[cpu].cluster_id)\n>>> #define topology_core_id(cpu) (cpu_topology[cpu].core_id)\n>>> #define topology_core_cpumask(cpu) (&cpu_topology[cpu].core_sibling)\n>>> #define topology_sibling_cpumask(cpu) (&cpu_topology[cpu].thread_sibling)\n>>> diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c\n>>> index 8d48b233e6ce..9147e5b6326d 100644\n>>> --- a/arch/arm64/kernel/topology.c\n>>> +++ b/arch/arm64/kernel/topology.c\n>>> @@ -67,6 +67,8 @@ static int __init parse_core(struct device_node *core, int cluster_id,\n>>> leaf = false;\n>>> cpu = get_cpu_for_node(t);\n>>> if (cpu >= 0) {\n>>> + /* maintain DT cluster == package behavior */\n>>> + cpu_topology[cpu].package_id = cluster_id;\n>>> cpu_topology[cpu].cluster_id = cluster_id;\n>>> cpu_topology[cpu].core_id = core_id;\n>>> cpu_topology[cpu].thread_id = i;\n>>> @@ -88,7 +90,7 @@ static int __init parse_core(struct device_node *core, int cluster_id,\n>>> core);\n>>> return -EINVAL;\n>>> }\n>>> -\n>>> + cpu_topology[cpu].package_id = cluster_id;\n>>> cpu_topology[cpu].cluster_id = cluster_id;\n>>> cpu_topology[cpu].core_id = core_id;\n>>> } else if (leaf) {\n>>> @@ -228,7 +230,7 @@ static void update_siblings_masks(unsigned int cpuid)\n>>> for_each_possible_cpu(cpu) {\n>>> cpu_topo = &cpu_topology[cpu];\n>>> - if (cpuid_topo->cluster_id != cpu_topo->cluster_id)\n>>> + if (cpuid_topo->package_id != cpu_topo->package_id)\n> \n> (note here that core_siblings now reflect the package_id rather than the cluster_id. This only matters if cluster_id!=package_id).\n> \n>>> continue;\n>>> cpumask_set_cpu(cpuid, &cpu_topo->core_sibling);\n>>> @@ -273,6 +275,7 @@ void store_cpu_topology(unsigned int cpuid)\n>>> MPIDR_AFFINITY_LEVEL(mpidr, 2) << 8 |\n>>> MPIDR_AFFINITY_LEVEL(mpidr, 3) << 16;\n>>> }\n>>> + cpuid_topo->package_id = cpuid_topo->cluster_id;\n>>> pr_debug(\"CPU%u: cluster %d core %d thread %d mpidr %#016llx\\n\",\n>>> cpuid, cpuid_topo->cluster_id, cpuid_topo->core_id,\n>>> @@ -292,6 +295,7 @@ static void __init reset_cpu_topology(void)\n>>> cpu_topo->thread_id = -1;\n>>> cpu_topo->core_id = 0;\n>>> cpu_topo->cluster_id = -1;\n>>> + cpu_topo->package_id = -1;\n>>> cpumask_clear(&cpu_topo->core_sibling);\n>>> cpumask_set_cpu(cpu, &cpu_topo->core_sibling);\n>>> diff --git a/include/linux/topology.h b/include/linux/topology.h\n>>> index cb0775e1ee4b..4660749a7303 100644\n>>> --- a/include/linux/topology.h\n>>> +++ b/include/linux/topology.h\n>>> @@ -184,6 +184,9 @@ static inline int cpu_to_mem(int cpu)\n>>> #ifndef topology_physical_package_id\n>>> #define topology_physical_package_id(cpu) ((void)(cpu), -1)\n>>> #endif\n>>> +#ifndef topology_cod_id /* cluster on die */\n>>> +#define topology_cod_id(cpu) topology_physical_package_id(cpu)\n>>> +#endif\n>>> #ifndef topology_core_id\n>>> #define topology_core_id(cpu) ((void)(cpu), 0)\n>>> #endif\n>>>\n>>\n>>\n>> _______________________________________________\n>> linux-arm-kernel mailing list\n>> linux-arm-kernel@lists.infradead.org\n>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel\n>>\n> \n> \n> .\n>","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org\n\theader.b=\"UxPKGFVK\"; dkim-atps=neutral"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xx4R24FrNz9s78\n\tfor ;\n\tTue, 19 Sep 2017 11:04:46 +1000 (AEST)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1du6xv-0000LQ-12; Tue, 19 Sep 2017 01:04:43 +0000","from szxga05-in.huawei.com ([45.249.212.191])\n\tby bombadil.infradead.org with esmtps (Exim 4.87 #1 (Red Hat Linux))\n\tid 1du6xo-0000Ex-Rn for linux-arm-kernel@lists.infradead.org;\n\tTue, 19 Sep 2017 01:04:40 +0000","from 172.30.72.59 (EHLO DGGEMS401-HUB.china.huawei.com)\n\t([172.30.72.59])\n\tby dggrg05-dlp.huawei.com (MOS 4.4.6-GA FastPath queued)\n\twith ESMTP id DHO20850; Tue, 19 Sep 2017 09:03:57 +0800 (CST)","from [127.0.0.1] (10.177.32.209) by DGGEMS401-HUB.china.huawei.com\n\t(10.3.19.201) with Microsoft SMTP Server id 14.3.301.0;\n\tTue, 19 Sep 2017 09:03:48 +0800"],"DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post:\n\tList-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:\n\tMessage-ID:From:References:To:Subject:Reply-To:Content-ID:Content-Description\n\t:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=K4HMJYRPsIeKtc14+eNFgJ3SikasRkdCcKcH8rWsKHI=;\n\tb=UxPKGFVKsApjtO\n\tqhxl9cMB4gbs98UNrE9MJwo5Xqc485Vv3LAwNEcCdSVUIMmwe/kZau68/uX0cU7kmZoFBrzvNxx2y\n\tTJfFZ43Zjo5+eaa5FXKEJuwe72N0aiyvFp6yjx2eHiSr10ZE/4IAcTkJ3M5NVzf9LHqgWETjR44sJ\n\tkcj7NhA8tjm9m+koREVcTeaLUTOG5MUwATswuC2eR5w+CC7QyKh86ijvPKMLIokXPNp5JSZeBBC9+\n\tqnwwmiZ2P6X5Rf/QD8znhMhTT+fQFduRAmmLGFInRkciTR+BUciBFU2F3Qw8jgBb84IC4zrg1DaEM\n\tWa8RQu21UvBMvoozpvAQ==;","Subject":"Re: [PATCH 4/6] Topology: Add cluster on die macros and arm64\n\tdecoding","To":"Jeremy Linton , ","References":"<20170914184918.20406-1-jeremy.linton@arm.com>\n\t<20170914184918.20406-5-jeremy.linton@arm.com>\n\t\n\t<8e145e4b-e1d2-cb15-2cf9-cace5fed524f@arm.com>","From":"Xiongfeng Wang ","Message-ID":"<1e41b605-371b-ee54-f251-ad58082d236e@huawei.com>","Date":"Tue, 19 Sep 2017 09:03:47 +0800","User-Agent":"Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101\n\tThunderbird/45.2.0","MIME-Version":"1.0","In-Reply-To":"<8e145e4b-e1d2-cb15-2cf9-cace5fed524f@arm.com>","X-Originating-IP":"[10.177.32.209]","X-CFilter-Loop":"Reflected","X-Mirapoint-Virus-RAPID-Raw":"score=unknown(0),\n\trefid=str=0001.0A020206.59C06CFE.0119, ss=1, re=0.000, recu=0.000,\n\treip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0,\n\tso=2014-11-16 11:51:01, dmn=2013-03-21 17:37:32","X-Mirapoint-Loop-Id":"cdc751937ad370a174055b31ce2ebcf4","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20170918_180437_595103_52C7B15B ","X-CRM114-Status":"GOOD ( 17.11 )","X-Spam-Score":"-1.9 (-)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-1.9 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay\n\tdomain\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"lorenzo.pieralisi@arm.com, austinwc@codeaurora.org, jhugo@codeaurora.org,\n\trjw@rjwysocki.net, john.garry@huawei.com, will.deacon@arm.com,\n\thanjun.guo@linaro.org, sudeep.holla@arm.com, catalin.marinas@arm.com, \n\tlinux-arm-kernel@lists.infradead.org","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}},{"id":1770604,"web_url":"http://patchwork.ozlabs.org/comment/1770604/","msgid":"<6ffb8142-d9ea-47f1-87e7-a226cda22b01@huawei.com>","list_archive_url":null,"date":"2017-09-19T01:41:01","subject":"Re: [PATCH 6/6] arm64: topology: Enable ACPI/PPTT based CPU\n\ttopology.","submitter":{"id":72343,"url":"http://patchwork.ozlabs.org/api/people/72343/","name":"Xiongfeng Wang","email":"wangxiongfeng2@huawei.com"},"content":"Hi Jeremy,\n\nOn 2017/9/19 3:02, Jeremy Linton wrote:\n> On 09/17/2017 08:37 PM, Xiongfeng Wang wrote:\n>> Hi Jeremy,\n>>\n>> On 2017/9/15 2:49, Jeremy Linton wrote:\n>>> Propagate the topology information from the PPTT tree to the\n>>> cpu_topology array. We can get the thread id, core_id and\n>>> cluster_id by assuming certain levels of the PPTT tree correspond\n>>> to those concepts. The package_id is flagged in the tree and can be\n>>> found by passing an arbitrary large level to setup_acpi_cpu_topology()\n>>> which terminates its search when it finds an ACPI node flagged\n>>> as the physical package. If the tree doesn't contain enough\n>>> levels to represent all of thread/core/cod/package then the package\n>>> id will be used for the missing levels.\n>>>\n>>> Since arm64 machines can have 3 distinct topology levels, and the\n>>> scheduler only handles sockets/threads well today, we compromise\n>>> by collapsing into one of three diffrent configurations. These are\n>>> thread/socket, thread/cluster or cluster/socket depending on whether\n>>> the machine has threading and multisocket, threading in a single\n>>> socket, or doesn't have threading.\n>>>\n>>> This code is loosely based on a combination of code from:\n>>> Xiongfeng Wang \n>>> John Garry \n>>> Jeffrey Hugo \n>>>\n>>> Signed-off-by: Jeremy Linton \n>>> ---\n>>> arch/arm64/kernel/topology.c | 68 +++++++++++++++++++++++++++++++++++++++++++-\n>>> include/linux/topology.h | 2 ++\n>>> 2 files changed, 69 insertions(+), 1 deletion(-)\n>>>\n>>> diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c\n>>> index 9147e5b6326d..8ee5cc5ba9bd 100644\n>>> --- a/arch/arm64/kernel/topology.c\n>>> +++ b/arch/arm64/kernel/topology.c\n>>> @@ -11,6 +11,7 @@\n>>> * for more details.\n>>> */\n>>> +#include \n>>> #include \n>>> #include \n>>> #include \n>>> @@ -22,6 +23,7 @@\n>>> #include \n>>> #include \n>>> #include \n>>> +#include \n>>> #include \n>>> #include \n>>> @@ -304,6 +306,68 @@ static void __init reset_cpu_topology(void)\n>>> }\n>>> }\n>>> +#ifdef CONFIG_ACPI\n>>> +/*\n>>> + * Propagate the topology information of the processor_topology_node tree to the\n>>> + * cpu_topology array.\n>>> + */\n>>> +static int __init parse_acpi_topology(void)\n>>> +{\n>>> + u64 is_threaded;\n>>> + int is_multisocket;\n>>> + int cpu;\n>>> + int topology_id;\n>>> + /* set a large depth, to hit ACPI_PPTT_PHYSICAL_PACKAGE if one exists */\n>>> + const int max_topo = 0xFF;\n>>> +\n>>> + is_threaded = read_cpuid_mpidr() & MPIDR_MT_BITMASK;\n>>> + is_multisocket = acpi_multisocket_count();\n>>> + if (is_multisocket < 0)\n>>> + return is_multisocket;\n>>> +\n>>> + for_each_possible_cpu(cpu) {\n>>> + topology_id = setup_acpi_cpu_topology(cpu, 0);\n>>> + if (topology_id < 0)\n>>> + return topology_id;\n>>> +\n>>> + if ((is_threaded) && (is_multisocket > 1)) {\n>>> + /* MT per core, and multiple sockets */\n>>> + cpu_topology[cpu].thread_id = topology_id;\n>>> + topology_id = setup_acpi_cpu_topology(cpu, 1);\n>>> + cpu_topology[cpu].core_id = topology_id;\n>>> + topology_id = setup_acpi_cpu_topology(cpu, 2);\n>>> + cpu_topology[cpu].cluster_id = topology_id;\n>>> + topology_id = setup_acpi_cpu_topology(cpu, max_topo);\n>>> + cpu_topology[cpu].package_id = topology_id;\n>>> + } else if (is_threaded) {\n>>> + /* mutltiple threads, but only a single socket */\n>>> + cpu_topology[cpu].thread_id = topology_id;\n>>> + topology_id = setup_acpi_cpu_topology(cpu, 1);\n>>> + cpu_topology[cpu].core_id = topology_id;\n>>> + topology_id = setup_acpi_cpu_topology(cpu, 2);\n>>> + cpu_topology[cpu].cluster_id = topology_id;\n>>> + cpu_topology[cpu].package_id = topology_id;\n>>> + } else {\n>>> + /* no threads, clusters behave like threads */\n>>> + cpu_topology[cpu].thread_id = topology_id;\n>>> + topology_id = setup_acpi_cpu_topology(cpu, 1);\n>>> + cpu_topology[cpu].core_id = topology_id;\n>>> + cpu_topology[cpu].cluster_id = topology_id;\n>>> + topology_id = setup_acpi_cpu_topology(cpu, max_topo);\n>>> + cpu_topology[cpu].package_id = topology_id;\n>>\n>> I can not understand why should we consider cores in a cluster as threads. The scheduler will\n>> be effected a lot by this. And the 'lstopo' may display wrong information.\n> \n> My take, is that we shouldn't be discarding the cluster information because its extremely valuable. In many ways it seems that clustered cores have, at a high level, \n> similar performance characteristics to threads (AKA, cores in a cluster have high performance when sharing data, but for problems with little sharing its more advantageous to \n> first schedule those threads to differing clusters). Although, how much affect this has vs the MC cache priorities in the scheduler isn't apparent to me.\nThe code for sched_domain building for arm64 is as below. 'cpu_smt_mask' use 'thread_sibling' in struct cpu_topology, and 'cpu_coregroup_mask' use 'core_sibling' in struct cpu_topology.\nBut the defconfig for ARM64 does not include 'CONFIG_SCHED_SMT'. If we add a *_sibling field in struct cpu_topology to represent cores in one cluster, and change 'cpu_coregroup_mask'\nto use this field, we can build a sched_domain only with cores in a cluster.\n\nstatic struct sched_domain_topology_level default_topology[] = {\n#ifdef CONFIG_SCHED_SMT\n { cpu_smt_mask, cpu_smt_flags, SD_INIT_NAME(SMT) },\n#endif\n#ifdef CONFIG_SCHED_MC\n { cpu_coregroup_mask, cpu_core_flags, SD_INIT_NAME(MC) },\n#endif\n { cpu_cpu_mask, SD_INIT_NAME(DIE) },\n { NULL, },\n};\n\n> \n> Anyway, lstopo doesn't currently know about anything beyond package/thread, except for the book. The question is, do we want to misuse the book_id to represent sockets and \n> continue to use cluster_id as the physical_package_id? I don't think that is a better plan than what I've done here.\n> \nSorry I didn't know much about the book_id. For my understanding, 'lstopo' use the information from the sysfs. So I search the linux code for 'book_id' and found out that\n'book_id' seems to be used in S390 architecture only.\n> \n> The bottom line, is that after having looked at the scheduler a bit, I suspect that thread=cluster for machines without MT doesn't' really matter much. So, the next version \n> i'm just going to collapse this into what everyone expects socket=socket and thread=thread for ACPI users (which are more likely to have NUMA and multisocket at this point). The \n> cluster knowledge is still somewhat visible to the scheduler via the cache topology.\n> \n> \n> \n> \n>>\n>> Thanks,\n>> Xiongfeng Wang\n>>\n>>> + }\n>>> + }\n>>> + return 0;\n>>> +}\n>>> +\n>>> +#else\n>>> +static int __init parse_acpi_topology(void)\n>>> +{\n>>> + /*ACPI kernels should be built with PPTT support*/\n>>> + return -EINVAL;\n>>> +}\n>>> +#endif\n>>> +\n>>> void __init init_cpu_topology(void)\n>>> {\n>>> reset_cpu_topology();\n>>> @@ -312,6 +376,8 @@ void __init init_cpu_topology(void)\n>>> * Discard anything that was parsed if we hit an error so we\n>>> * don't use partial information.\n>>> */\n>>> - if (of_have_populated_dt() && parse_dt_topology())\n>>> + if ((!acpi_disabled) && parse_acpi_topology())\n>>> + reset_cpu_topology();\n>>> + else if (of_have_populated_dt() && parse_dt_topology())\n>>> reset_cpu_topology();\n>>> }\n>>> diff --git a/include/linux/topology.h b/include/linux/topology.h\n>>> index 4660749a7303..08bf736be7c1 100644\n>>> --- a/include/linux/topology.h\n>>> +++ b/include/linux/topology.h\n>>> @@ -43,6 +43,8 @@\n>>> if (nr_cpus_node(node))\n>>> int arch_update_cpu_topology(void);\n>>> +int setup_acpi_cpu_topology(unsigned int cpu, int level);\n>>> +int acpi_multisocket_count(void);\n>>> /* Conform to ACPI 2.0 SLIT distance definitions */\n>>> #define LOCAL_DISTANCE 10\n>>>\n>>\n> \n> \n> .\n>","headers":{"Return-Path":"","X-Original-To":"incoming-imx@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming-imx@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=lists.infradead.org\n\t(client-ip=65.50.211.133; helo=bombadil.infradead.org;\n\tenvelope-from=linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=lists.infradead.org\n\theader.i=@lists.infradead.org\n\theader.b=\"eLmABnRf\"; dkim-atps=neutral"],"Received":["from bombadil.infradead.org (bombadil.infradead.org\n\t[65.50.211.133])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xx5Fs1kFJz9ryQ\n\tfor ;\n\tTue, 19 Sep 2017 11:41:51 +1000 (AEST)","from localhost ([127.0.0.1] helo=bombadil.infradead.org)\n\tby bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux))\n\tid 1du7Xm-0007Er-F1; Tue, 19 Sep 2017 01:41:46 +0000","from szxga05-in.huawei.com ([45.249.212.191])\n\tby bombadil.infradead.org with esmtps (Exim 4.87 #1 (Red Hat Linux))\n\tid 1du7Xi-00077j-32 for linux-arm-kernel@lists.infradead.org;\n\tTue, 19 Sep 2017 01:41:44 +0000","from 172.30.72.59 (EHLO DGGEMS412-HUB.china.huawei.com)\n\t([172.30.72.59])\n\tby dggrg05-dlp.huawei.com (MOS 4.4.6-GA FastPath queued)\n\twith ESMTP id DHO26288; Tue, 19 Sep 2017 09:41:13 +0800 (CST)","from [127.0.0.1] (10.177.32.209) by DGGEMS412-HUB.china.huawei.com\n\t(10.3.19.212) with Microsoft SMTP Server id 14.3.301.0;\n\tTue, 19 Sep 2017 09:41:02 +0800"],"DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=lists.infradead.org; s=bombadil.20170209; h=Sender:\n\tContent-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post:\n\tList-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:\n\tMessage-ID:From:References:To:Subject:Reply-To:Content-ID:Content-Description\n\t:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:\n\tList-Owner; bh=iGAfY1A5rl6/DGdiQTvCXAbDNxCm+4rfC8HDtdOUu0U=;\n\tb=eLmABnRfgY0fYs\n\tspdje4wP5hBvzxtgYP89fqEzn5xLcMpBlCQcL/5fntUoFo4RCuMUcEHYFLPLWg1ihX1ohJkxNbFXc\n\tpDYHne6mi1JcuQXMTZdba+EIKBkvATnep/aK3YdAuxFHJ1CRk9BeQ36F/igOqP9QMHqtv3KlhAhLA\n\tf/FUFc7GWdwjLFTUKhAGagu4P4Q54CVYu0OZCDT0G3P467GONB5khYOX059GDU/y+V+l29gOKm0q5\n\t7trPayXKLLtcju1ObFNs2SW/epLDf6+QDS+uCVZ2qx7uuEyEyPUoJXfZJUe96Ic9m4aKs9M6+fQeS\n\t/vc+fZM9R2OWJe+c9/Rg==;","Subject":"Re: [PATCH 6/6] arm64: topology: Enable ACPI/PPTT based CPU\n\ttopology.","To":"Jeremy Linton , ","References":"<20170914184918.20406-1-jeremy.linton@arm.com>\n\t<20170914184918.20406-7-jeremy.linton@arm.com>\n\t<93846e2c-df62-fda6-200a-f55bfb9955c4@huawei.com>\n\t<9a8e13d6-4b5e-cfa2-44c4-4d79aca94800@arm.com>","From":"Xiongfeng Wang ","Message-ID":"<6ffb8142-d9ea-47f1-87e7-a226cda22b01@huawei.com>","Date":"Tue, 19 Sep 2017 09:41:01 +0800","User-Agent":"Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101\n\tThunderbird/45.2.0","MIME-Version":"1.0","In-Reply-To":"<9a8e13d6-4b5e-cfa2-44c4-4d79aca94800@arm.com>","X-Originating-IP":"[10.177.32.209]","X-CFilter-Loop":"Reflected","X-Mirapoint-Virus-RAPID-Raw":"score=unknown(0),\n\trefid=str=0001.0A090202.59C075BB.0002, ss=1, re=0.000, recu=0.000,\n\treip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0,\n\tso=2014-11-16 11:51:01, dmn=2013-03-21 17:37:32","X-Mirapoint-Loop-Id":"8b6f4713633aacf6c106bb7e1b3e956f","X-CRM114-Version":"20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 ","X-CRM114-CacheID":"sfid-20170918_184142_648020_8E2FDC5B ","X-CRM114-Status":"GOOD ( 22.39 )","X-Spam-Score":"-1.9 (-)","X-Spam-Report":"SpamAssassin version 3.4.1 on bombadil.infradead.org summary:\n\tContent analysis details: (-1.9 points)\n\tpts rule name description\n\t---- ----------------------\n\t--------------------------------------------------\n\t-0.0 SPF_PASS SPF: sender matches SPF record\n\t-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay\n\tdomain\n\t-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%\n\t[score: 0.0000]","X-BeenThere":"linux-arm-kernel@lists.infradead.org","X-Mailman-Version":"2.1.21","Precedence":"list","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"lorenzo.pieralisi@arm.com, austinwc@codeaurora.org, jhugo@codeaurora.org,\n\twill.deacon@arm.com, john.garry@huawei.com, rjw@rjwysocki.net,\n\thanjun.guo@linaro.org, sudeep.holla@arm.com, catalin.marinas@arm.com, \n\tlinux-arm-kernel@lists.infradead.org","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"7bit","Sender":"\"linux-arm-kernel\" ","Errors-To":"linux-arm-kernel-bounces+incoming-imx=patchwork.ozlabs.org@lists.infradead.org","List-Id":"linux-imx-kernel.lists.patchwork.ozlabs.org"}}]