linux-riscv.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: "Andrew F. Davis" <afd@ti.com>
To: Morten Rasmussen <morten.rasmussen@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	"Peter Zijlstra \(Intel\)" <peterz@infradead.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Linus Walleij <linus.walleij@linaro.org>,
	Palmer Dabbelt <palmer@sifive.com>,
	Will Deacon <will.deacon@arm.com>,
	Atish Patra <atish.patra@wdc.com>,
	Mauro Carvalho Chehab <mchehab+samsung@kernel.org>,
	linux-riscv@lists.infradead.org, Ingo Molnar <mingo@kernel.org>,
	Rob Herring <robh@kernel.org>, Anup Patel <anup@brainfault.org>,
	Russell King <linux@armlinux.org.uk>,
	devicetree@vger.kernel.org, Albert Ou <aou@eecs.berkeley.edu>,
	Rob Herring <robh+dt@kernel.org>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	linux-arm-kernel@lists.infradead.org,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-kernel@vger.kernel.org,
	Jeremy Linton <jeremy.linton@arm.com>,
	Otto Sabart <ottosabart@seberm.com>,
	Sudeep Holla <sudeep.holla@arm.com>,
	"David S. Miller" <davem@davemloft.net>
Subject: Re: [PATCH v6 1/7] Documentation: DT: arm: add support for sockets defining package boundaries
Date: Thu, 30 May 2019 08:56:03 -0400	[thread overview]
Message-ID: <70639181-09d1-4644-f062-b19e06db7471@ti.com> (raw)
In-Reply-To: <20190530115103.GA10919@e105550-lin.cambridge.arm.com>

On 5/30/19 7:51 AM, 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 <sudeep.holla@arm.com>
>>>
>>> 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.
> 

I see the benefit of reporting the physical layout and packaging 
information to user-space for tracking reasons, but from software 
perspective this doesn't matter, and the resource partitioning should be 
described elsewhere (NUMA nodes being the go to example).

> At the moment user-space is only told about hw threads, cores, and
> sockets. In the very near future it is going to be told about dies too
> (look for Len Brown's multi-die patch set).
> 

Seems my hypothetical case is already in the works :(

> I don't see how we can provide correct information to user-space based
> on the current information in DT. I'm not convinced it was a good idea
> to expose this information to user-space to begin with but that is
> another discussion.
> 

Fair enough, it's a little late now to un-expose this info to userspace 
so we should at least present it correctly. My worry was this getting 
out of hand with layering, for instance what happens when we need to add 
die nodes in-between cluster and socket?

Andrew

> Morten
> 

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

  reply	other threads:[~2019-05-30 12:56 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-29 21:13 [PATCH v6 0/7] Unify CPU topology across ARM & RISC-V Atish Patra
2019-05-29 21:13 ` [PATCH v6 1/7] Documentation: DT: arm: add support for sockets defining package boundaries Atish Patra
2019-05-29 23:39   ` Andrew F. Davis
2019-05-30 11:51     ` Morten Rasmussen
2019-05-30 12:56       ` Andrew F. Davis [this message]
2019-05-30 13:12         ` Morten Rasmussen
2019-05-31  9:41         ` Sudeep Holla
2019-05-30 21:42       ` Russell King - ARM Linux admin
2019-05-31  9:37         ` Sudeep Holla
2019-05-31  9:54           ` Morten Rasmussen
2019-05-29 21:13 ` [PATCH v6 2/7] dt-binding: cpu-topology: Move cpu-map to a common binding Atish Patra
2019-05-30 20:55   ` Jeremy Linton
2019-06-03  8:49     ` Atish Patra
2019-06-03  9:05       ` Sudeep Holla
2019-05-29 21:13 ` [PATCH v6 3/7] cpu-topology: Move cpu topology code to common code Atish Patra
2019-06-06 14:26   ` Atish Patra
2019-06-11 15:55   ` Will Deacon
2019-05-29 21:13 ` [PATCH v6 4/7] arm: Use common cpu_topology structure and functions Atish Patra
2019-06-06 14:25   ` Atish Patra
2019-05-29 21:13 ` [PATCH v6 5/7] RISC-V: Parse cpu topology during boot Atish Patra
2019-06-07  5:00   ` Paul Walmsley
2019-05-29 21:13 ` [PATCH v6 6/7] base: arch_topology: update Kconfig help description Atish Patra
2019-05-29 21:13 ` [PATCH v6 7/7] MAINTAINERS: Add an entry for generic architecture topology Atish Patra
2019-05-30 21:12 ` [PATCH v6 0/7] Unify CPU topology across ARM & RISC-V Jeremy Linton
2019-06-03  8:50   ` Atish Patra

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=70639181-09d1-4644-f062-b19e06db7471@ti.com \
    --to=afd@ti.com \
    --cc=anup@brainfault.org \
    --cc=aou@eecs.berkeley.edu \
    --cc=atish.patra@wdc.com \
    --cc=catalin.marinas@arm.com \
    --cc=davem@davemloft.net \
    --cc=devicetree@vger.kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=jeremy.linton@arm.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=linux@armlinux.org.uk \
    --cc=mark.rutland@arm.com \
    --cc=mchehab+samsung@kernel.org \
    --cc=mingo@kernel.org \
    --cc=morten.rasmussen@arm.com \
    --cc=ottosabart@seberm.com \
    --cc=palmer@sifive.com \
    --cc=paul.walmsley@sifive.com \
    --cc=peterz@infradead.org \
    --cc=rafael@kernel.org \
    --cc=robh+dt@kernel.org \
    --cc=robh@kernel.org \
    --cc=sudeep.holla@arm.com \
    --cc=tglx@linutronix.de \
    --cc=will.deacon@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).