From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.0 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,T_DKIMWL_WL_HIGH autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C075DC28CC0 for ; Wed, 29 May 2019 23:40:05 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 8E76D2437C for ; Wed, 29 May 2019 23:40:05 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="iL+JFQH4"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=ti.com header.i=@ti.com header.b="xY2rvs6J" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8E76D2437C Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=ti.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender:Content-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=9NnULrrWQWJrrniP7ny0EmJXDt7uPg7FfNUDDlvbkwM=; b=iL+JFQH4H9wIaShVDYndaiI52 qSpmfYFRGxMbyGaFaI86vxKcDP5vaSNa5yqtZrgFuwBSt70AmFRCrZTH7JGG/pxwKT0z1zicAXUNA iLR3oexUaZQMZgqM51UXHguvq0mJN7BdSuyZmqQRy6kXrLLkVFpv2PnD87Skk8ZDelE0b7So4Wnhd tMGH6jnZvINfvbC9IgJ9lE7J9skT79VI6LRRPwtsn9x8LLjMS8G5ANuh3359VbGNKT0v5e1msnraY nlaUoItVQL13a204yKddXIekIiv6o3NYJ+y4Zgf8PQvxES+lnojdDbZf6CH56I2yjETWGTHiRKRPd 45suGNOpA==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1hW8As-0002z9-AA; Wed, 29 May 2019 23:40:02 +0000 Received: from fllv0015.ext.ti.com ([198.47.19.141]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1hW8An-0002wm-EF; Wed, 29 May 2019 23:39:59 +0000 Received: from fllv0034.itg.ti.com ([10.64.40.246]) by fllv0015.ext.ti.com (8.15.2/8.15.2) with ESMTP id x4TNdJpm045204; Wed, 29 May 2019 18:39:19 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1559173159; bh=Ob84HKBpBDTg+9kN26JNOTwj7/pKEiiBDZ6BFO8Ly2U=; h=Subject:To:CC:References:From:Date:In-Reply-To; b=xY2rvs6J1JpuBlyy+QK2mc2U+I9JjBnLA9VbnplG4BQTLpqWB6Sy2mLxg0bScLBP+ AsIR4ArxnHRQR06r62fnlVI6hmyb0msh3tnY7DFPIz6e9YSbJdKWdgQu5v2K17bDir NJ1d/9hWtstSKtlXQsqgM+k1Wl4t4uzwP2QRlv6c= Received: from DLEE105.ent.ti.com (dlee105.ent.ti.com [157.170.170.35]) by fllv0034.itg.ti.com (8.15.2/8.15.2) with ESMTPS id x4TNdJsX105229 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 29 May 2019 18:39:19 -0500 Received: from DLEE109.ent.ti.com (157.170.170.41) by DLEE105.ent.ti.com (157.170.170.35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Wed, 29 May 2019 18:39:18 -0500 Received: from lelv0327.itg.ti.com (10.180.67.183) by DLEE109.ent.ti.com (157.170.170.41) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5 via Frontend Transport; Wed, 29 May 2019 18:39:19 -0500 Received: from [10.250.93.148] (ileax41-snat.itg.ti.com [10.172.224.153]) by lelv0327.itg.ti.com (8.15.2/8.15.2) with ESMTP id x4TNdHmh064568; Wed, 29 May 2019 18:39:17 -0500 Subject: Re: [PATCH v6 1/7] Documentation: DT: arm: add support for sockets defining package boundaries To: Atish Patra , References: <20190529211340.17087-1-atish.patra@wdc.com> <20190529211340.17087-2-atish.patra@wdc.com> From: "Andrew F. Davis" Message-ID: <49f41e62-5354-a674-d95f-5f63851a0ca6@ti.com> Date: Wed, 29 May 2019 19:39:17 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <20190529211340.17087-2-atish.patra@wdc.com> Content-Language: en-US X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190529_163957_562500_6B89DBE9 X-CRM114-Status: GOOD ( 30.67 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , "Rafael J. Wysocki" , "Peter Zijlstra \(Intel\)" , Catalin Marinas , Linus Walleij , Palmer Dabbelt , Will Deacon , Mauro Carvalho Chehab , linux-riscv@lists.infradead.org, Ingo Molnar , Rob Herring , Anup Patel , Russell King , Morten Rasmussen , devicetree@vger.kernel.org, Albert Ou , Rob Herring , Paul Walmsley , Thomas Gleixner , linux-arm-kernel@lists.infradead.org, Greg Kroah-Hartman , Jeremy Linton , Otto Sabart , Sudeep Holla , "David S. Miller" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 5/29/19 5:13 PM, Atish Patra wrote: > From: Sudeep Holla > > The current ARM DT topology description provides the operating system > with a topological view of the system that is based on leaf nodes > representing either cores or threads (in an SMT system) and a > hierarchical set of cluster nodes that creates a hierarchical topology > view of how those cores and threads are grouped. > > However this hierarchical representation of clusters does not allow to > describe what topology level actually represents the physical package or > the socket boundary, which is a key piece of information to be used by > an operating system to optimize resource allocation and scheduling. > Are physical package descriptions really needed? What does "socket" imply that a higher layer "cluster" node grouping does not? It doesn't imply a different NUMA distance and the definition of "socket" is already not well defined, is a dual chiplet processor not just a fancy dual "socket" or are dual "sockets" on a server board "slotket" card, will we need new names for those too.. Andrew > Lets add a new "socket" node type in the cpu-map node to describe the > same. > > Signed-off-by: Sudeep Holla > Reviewed-by: Rob Herring > --- > .../devicetree/bindings/arm/topology.txt | 52 ++++++++++++++----- > 1 file changed, 39 insertions(+), 13 deletions(-) > > diff --git a/Documentation/devicetree/bindings/arm/topology.txt b/Documentation/devicetree/bindings/arm/topology.txt > index b0d80c0fb265..3b8febb46dad 100644 > --- a/Documentation/devicetree/bindings/arm/topology.txt > +++ b/Documentation/devicetree/bindings/arm/topology.txt > @@ -9,6 +9,7 @@ ARM topology binding description > In an ARM system, the hierarchy of CPUs is defined through three entities that > are used to describe the layout of physical CPUs in the system: > > +- socket > - cluster > - core > - thread > @@ -63,21 +64,23 @@ nodes are listed. > > The cpu-map node's child nodes can be: > > - - one or more cluster nodes > + - one or more cluster nodes or > + - one or more socket nodes in a multi-socket system > > Any other configuration is considered invalid. > > -The cpu-map node can only contain three types of child nodes: > +The cpu-map node can only contain 4 types of child nodes: > > +- socket node > - cluster node > - core node > - thread node > > whose bindings are described in paragraph 3. > > -The nodes describing the CPU topology (cluster/core/thread) can only > -be defined within the cpu-map node and every core/thread in the system > -must be defined within the topology. Any other configuration is > +The nodes describing the CPU topology (socket/cluster/core/thread) can > +only be defined within the cpu-map node and every core/thread in the > +system must be defined within the topology. Any other configuration is > invalid and therefore must be ignored. > > =========================================== > @@ -85,26 +88,44 @@ invalid and therefore must be ignored. > =========================================== > > cpu-map child nodes must follow a naming convention where the node name > -must be "clusterN", "coreN", "threadN" depending on the node type (ie > -cluster/core/thread) (where N = {0, 1, ...} is the node number; nodes which > -are siblings within a single common parent node must be given a unique and > +must be "socketN", "clusterN", "coreN", "threadN" depending on the node type > +(ie socket/cluster/core/thread) (where N = {0, 1, ...} is the node number; nodes > +which are siblings within a single common parent node must be given a unique and > sequential N value, starting from 0). > cpu-map child nodes which do not share a common parent node can have the same > name (ie same number N as other cpu-map child nodes at different device tree > levels) since name uniqueness will be guaranteed by the device tree hierarchy. > > =========================================== > -3 - cluster/core/thread node bindings > +3 - socket/cluster/core/thread node bindings > =========================================== > > -Bindings for cluster/cpu/thread nodes are defined as follows: > +Bindings for socket/cluster/cpu/thread nodes are defined as follows: > + > +- socket node > + > + Description: must be declared within a cpu-map node, one node > + per physical socket in the system. A system can > + contain single or multiple physical socket. > + The association of sockets and NUMA nodes is beyond > + the scope of this bindings, please refer [2] for > + NUMA bindings. > + > + This node is optional for a single socket system. > + > + The socket node name must be "socketN" as described in 2.1 above. > + A socket node can not be a leaf node. > + > + A socket node's child nodes must be one or more cluster nodes. > + > + Any other configuration is considered invalid. > > - cluster node > > Description: must be declared within a cpu-map node, one node > per cluster. A system can contain several layers of > - clustering and cluster nodes can be contained in parent > - cluster nodes. > + clustering within a single physical socket and cluster > + nodes can be contained in parent cluster nodes. > > The cluster node name must be "clusterN" as described in 2.1 above. > A cluster node can not be a leaf node. > @@ -164,13 +185,15 @@ Bindings for cluster/cpu/thread nodes are defined as follows: > 4 - Example dts > =========================================== > > -Example 1 (ARM 64-bit, 16-cpu system, two clusters of clusters): > +Example 1 (ARM 64-bit, 16-cpu system, two clusters of clusters in a single > +physical socket): > > cpus { > #size-cells = <0>; > #address-cells = <2>; > > cpu-map { > + socket0 { > cluster0 { > cluster0 { > core0 { > @@ -253,6 +276,7 @@ cpus { > }; > }; > }; > + }; > > CPU0: cpu@0 { > device_type = "cpu"; > @@ -473,3 +497,5 @@ cpus { > =============================================================================== > [1] ARM Linux kernel documentation > Documentation/devicetree/bindings/arm/cpus.yaml > +[2] Devicetree NUMA binding description > + Documentation/devicetree/bindings/numa.txt > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel