From: morten.rasmussen@arm.com (Morten Rasmussen)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v7 13/13] arm64: topology: divorce MC scheduling domain from core_siblings
Date: Wed, 14 Mar 2018 12:43:02 +0000 [thread overview]
Message-ID: <20180314124302.GL4589@e105550-lin.cambridge.arm.com> (raw)
In-Reply-To: <d6497158-c58f-4fd4-4613-699fb2af7a61@gmail.com>
On Thu, Mar 08, 2018 at 09:41:17PM +0100, Brice Goglin wrote:
>
> > Is there a good reason for diverging instead of adjusting the
> > core_sibling mask? On x86 the core_siblings mask is defined by the last
> > level cache span so they don't have this issue.
>
> No. core_siblings is defined as the list of cores that have the same
> physical_package_id (see the doc of sysfs topology files), and LLC can
> be smaller than that.
> Example with E5v3 with cluster-on-die (two L3 per package, core_siblings
> is twice larger than L3 cpumap):
> https://www.open-mpi.org/projects/hwloc/lstopo/images/2XeonE5v3.v1.11.png
> On AMD EPYC, you even have up to 8 LLC per package.
Right, I missed the fact that x86 reports a different cpumask for
topology_core_cpumask() which defines the core_siblings exported through
sysfs than the mask used to define MC level in the scheduler topology.
The sysfs core_siblings is defined by the package_id, while the MC level
is defined by the LLC.
Thanks for pointing this out.
On arm64 MC level and sysfs core_siblings are currently defined using
the same mask, but we can't break sysfs, so using different masks is the
only option.
Morten
next prev parent reply other threads:[~2018-03-14 12:43 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-28 22:06 [PATCH v7 00/13] Support PPTT for ARM64 Jeremy Linton
2018-02-28 22:06 ` [PATCH v7 01/13] drivers: base: cacheinfo: move cache_setup_of_node() Jeremy Linton
2018-03-06 16:16 ` Sudeep Holla
2018-02-28 22:06 ` [PATCH v7 02/13] drivers: base: cacheinfo: setup DT cache properties early Jeremy Linton
2018-02-28 22:34 ` Palmer Dabbelt
2018-03-06 16:43 ` Sudeep Holla
2018-02-28 22:06 ` [PATCH v7 03/13] cacheinfo: rename of_node to fw_token Jeremy Linton
2018-03-06 16:45 ` Sudeep Holla
2018-02-28 22:06 ` [PATCH v7 04/13] arm64/acpi: Create arch specific cpu to acpi id helper Jeremy Linton
2018-03-06 17:13 ` Sudeep Holla
2018-02-28 22:06 ` [PATCH v7 05/13] ACPI/PPTT: Add Processor Properties Topology Table parsing Jeremy Linton
2018-03-06 17:39 ` Sudeep Holla
2018-03-08 16:39 ` Ard Biesheuvel
2018-03-08 19:52 ` Jeremy Linton
2018-03-19 10:46 ` Rafael J. Wysocki
2018-03-20 13:25 ` Jeremy Linton
2018-02-28 22:06 ` [PATCH v7 06/13] ACPI: Enable PPTT support on ARM64 Jeremy Linton
2018-03-06 16:55 ` Sudeep Holla
2018-02-28 22:06 ` [PATCH v7 07/13] drivers: base cacheinfo: Add support for ACPI based firmware tables Jeremy Linton
2018-03-06 17:50 ` Sudeep Holla
2018-03-08 17:20 ` Lorenzo Pieralisi
2018-02-28 22:06 ` [PATCH v7 08/13] arm64: " Jeremy Linton
2018-03-03 21:58 ` kbuild test robot
2018-03-06 17:23 ` Sudeep Holla
2018-02-28 22:06 ` [PATCH v7 09/13] ACPI/PPTT: Add topology parsing code Jeremy Linton
2018-02-28 22:06 ` [PATCH v7 10/13] arm64: topology: rename cluster_id Jeremy Linton
2018-03-05 12:24 ` Mark Brown
2018-02-28 22:06 ` [PATCH v7 11/13] arm64: topology: enable ACPI/PPTT based CPU topology Jeremy Linton
2018-02-28 22:06 ` [PATCH v7 12/13] ACPI: Add PPTT to injectable table list Jeremy Linton
2018-02-28 22:06 ` [PATCH v7 13/13] arm64: topology: divorce MC scheduling domain from core_siblings Jeremy Linton
2018-03-01 15:52 ` Morten Rasmussen
2018-02-27 20:18 ` Jeremy Linton
2018-03-06 16:07 ` Morten Rasmussen
2018-03-06 22:22 ` Jeremy Linton
2018-03-07 13:06 ` Morten Rasmussen
2018-03-07 16:19 ` Jeremy Linton
2018-03-14 13:05 ` Morten Rasmussen
2018-03-08 20:41 ` Brice Goglin
2018-03-14 12:43 ` Morten Rasmussen [this message]
2018-03-01 12:06 ` [PATCH v7 00/13] Support PPTT for ARM64 Sudeep Holla
2018-02-27 18:49 ` Jeremy Linton
2018-03-08 15:59 ` Ard Biesheuvel
2018-03-08 17:41 ` Jeremy Linton
2018-03-14 9:57 ` vkilari at codeaurora.org
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=20180314124302.GL4589@e105550-lin.cambridge.arm.com \
--to=morten.rasmussen@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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).