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=-2.5 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, T_DKIMWL_WL_HIGH,URIBL_BLOCKED,USER_AGENT_MUTT autolearn=unavailable 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 6B49DC28CC2 for ; Fri, 31 May 2019 09:54:56 +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 427E62673F for ; Fri, 31 May 2019 09:54:56 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="HxAVM2Jh" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 427E62673F Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.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-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=G+SMeRDjhJNDfj771gfGCVns4Xvvek02lD8Qklt4D5s=; b=HxAVM2Jh7CZ6n5 eCLBNJxFEsUUouomaCMxEeTD3BSt0LSNh18/70Tg+U4oYCHA0zCJVrWsnG+BtxyK0yBcdq2vIivl2 CLq8TvFjPq/5jdyFOm6f3oW2QbWAaP1D6Rrd59mNgFxb6aY0XsuhS43DTFcbO2xvEp41qnHwKNYIK wcaiDGNjxjscMJbypE9pS9zjpo+BUAhF8hoWQhgX0bGTFjIeIQbTkpQEvxGyvndPbzIhPomDMzRKz QSJ40QwyNQ1AVlSunTG00WeqqaHcLvRgzTLrevDSrj3aYQt1/QLbKWDgxtQLPgUjei7lRE0A/xXia EGFPagHxtz19q1T91SKQ==; 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 1hWeFK-0000sQ-C1; Fri, 31 May 2019 09:54:46 +0000 Received: from foss.arm.com ([217.140.101.70]) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1hWeFG-0000rK-De; Fri, 31 May 2019 09:54:43 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id CFAB5341; Fri, 31 May 2019 02:54:34 -0700 (PDT) Received: from e105550-lin.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 8F9353F59C; Fri, 31 May 2019 02:54:30 -0700 (PDT) Date: Fri, 31 May 2019 10:54:28 +0100 From: Morten Rasmussen To: Sudeep Holla Subject: Re: [PATCH v6 1/7] Documentation: DT: arm: add support for sockets defining package boundaries Message-ID: <20190531095428.GC10919@e105550-lin.cambridge.arm.com> References: <20190529211340.17087-1-atish.patra@wdc.com> <20190529211340.17087-2-atish.patra@wdc.com> <49f41e62-5354-a674-d95f-5f63851a0ca6@ti.com> <20190530115103.GA10919@e105550-lin.cambridge.arm.com> <20190530214254.tuxsnyv52a2fyhck@shell.armlinux.org.uk> <20190531093743.GB18292@e107155-lin> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20190531093743.GB18292@e107155-lin> User-Agent: Mutt/1.5.24 (2015-08-30) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190531_025442_479242_2F2CC7CA X-CRM114-Status: GOOD ( 23.00 ) 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 , Atish Patra , Mauro Carvalho Chehab , linux-riscv@lists.infradead.org, Ingo Molnar , Rob Herring , Anup Patel , Russell King - ARM Linux admin , devicetree@vger.kernel.org, Albert Ou , Rob Herring , Paul Walmsley , Thomas Gleixner , linux-arm-kernel@lists.infradead.org, Greg Kroah-Hartman , linux-kernel@vger.kernel.org, Jeremy Linton , "Andrew F. Davis" , Otto Sabart , "David S. Miller" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, May 31, 2019 at 10:37:43AM +0100, Sudeep Holla wrote: > On Thu, May 30, 2019 at 10:42:54PM +0100, Russell King - ARM Linux admin wrote: > > On Thu, May 30, 2019 at 12:51:03PM +0100, Morten Rasmussen wrote: > > > On Wed, May 29, 2019 at 07:39:17PM -0400, Andrew F. Davis wrote: > > > > 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.. > > > > > > Socket (or package) just implies what you suggest, a grouping of CPUs > > > based on the physical socket (or package). Some resources might be > > > associated with packages and more importantly socket information is > > > exposed to user-space. At the moment clusters are being exposed to > > > user-space as sockets which is less than ideal for some topologies. > > > > Please point out a 32-bit ARM system that has multiple "socket"s. > > > > As far as I'm aware, all 32-bit systems do not have socketed CPUs > > (modern ARM CPUs are part of a larger SoC), and the CPUs are always > > in one package. > > > > Even the test systems I've seen do not have socketed CPUs. > > > > As far as we know, there's none. So we simply have to assume all > those systems are single socket(IOW all CPUs reside inside a single > SoC package) system. Right, but we don't make that assumption. Clusters are reported as sockets/packages for arm, just like they are for arm64. My comment above applied to what can be described using DT, not what systems actually exists. We need to be able describe packages for architecture where we can't make assumptions. arm example (ARM TC2): root@morras01-tc2:~# lstopo Machine (985MB) Package L#0 Core L#0 + PU L#0 (P#0) Core L#1 + PU L#1 (P#1) Package L#1 Core L#2 + PU L#2 (P#2) Core L#3 + PU L#3 (P#3) Core L#4 + PU L#4 (P#4) Morten _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel