From: Morten Rasmussen <morten.rasmussen@arm.com>
To: Xiongfeng Wang <wangxiongfeng2@huawei.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
Jeremy Linton <jeremy.linton@arm.com>,
linux-acpi@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
sudeep.holla@arm.com, hanjun.guo@linaro.org, rjw@rjwysocki.net,
will.deacon@arm.com, catalin.marinas@arm.com,
gregkh@linuxfoundation.org, viresh.kumar@linaro.org,
mark.rutland@arm.com, linux-kernel@vger.kernel.org,
linux-pm@vger.kernel.org, jhugo@codeaurora.org,
Jonathan.Zhang@cavium.com, ahs3@redhat.com,
Jayachandran.Nair@cavium.com, austinwc@codeaurora.org,
lenb@kernel.org, vkilari@codeaurora.org,
Juri Lelli <juri.lelli@arm.com>
Subject: Re: [PATCH v6 11/12] arm64: topology: enable ACPI/PPTT based CPU topology
Date: Thu, 1 Mar 2018 14:19:03 +0000 [thread overview]
Message-ID: <20180301141903.GH4589@e105550-lin.cambridge.arm.com> (raw)
In-Reply-To: <2d248f08-79b6-d5e2-7e34-31a21efcdc07@huawei.com>
On Sat, Feb 24, 2018 at 11:05:53AM +0800, Xiongfeng Wang wrote:
>
> Hi,
> On 2018/2/23 19:02, Lorenzo Pieralisi wrote:
> > On Thu, Jan 25, 2018 at 09:56:30AM -0600, Jeremy Linton wrote:
> >> Hi,
> >>
> >> On 01/25/2018 06:15 AM, Xiongfeng Wang wrote:
> >>> Hi Jeremy,
> >>>
> >>> I have tested the patch with the newest UEFI. It prints the below error:
> >>>
> >>> [ 4.017371] BUG: arch topology borken
> >>> [ 4.021069] BUG: arch topology borken
> >>> [ 4.024764] BUG: arch topology borken
> >>> [ 4.028460] BUG: arch topology borken
> >>> [ 4.032153] BUG: arch topology borken
> >>> [ 4.035849] BUG: arch topology borken
> >>> [ 4.039543] BUG: arch topology borken
> >>> [ 4.043239] BUG: arch topology borken
> >>> [ 4.046932] BUG: arch topology borken
> >>> [ 4.050629] BUG: arch topology borken
> >>> [ 4.054322] BUG: arch topology borken
> >>>
> >>> I checked the code and found that the newest UEFI set PPTT physical_package_flag on a physical package node and
> >>> the NUMA domain (SRAT domains) starts from the layer of DIE. (The topology of our board is core->cluster->die->package).
> >>
> >> I commented about that on the EDK2 mailing list. While the current spec
> >> doesn't explicitly ban having the flag set multiple times between the leaf
> >> and the root I consider it a "bug" and there is an effort to clarify the
> >> spec and the use of that flag.
> >>>
> >>> When the kernel starts to build sched_domain, the multi-core sched_domain contains all the cores within a package,
> >>> and the lowest NUMA sched_domain contains all the cores within a die. But the kernel requires that the multi-core
> >>> sched_domain should be a subset of the lowest NUMA sched_domain, so the BUG info is printed.
> >>
> >> Right. I've mentioned this problem a couple of times.
> >>
> >> At at the moment, the spec isn't clear about how the proximity domain is
> >> detected/located within the PPTT topology (a node with a 1:1 correspondence
> >> isn't even required). As you can see from this patch set, we are making the
> >> general assumption that the proximity domains are at the same level as the
> >> physical socket. This isn't ideal for NUMA topologies, like the D05, that
> >> don't align with the physical socket.
> >>
> >> There are efforts underway to clarify and expand upon the specification to
> >> deal with this general problem. The simple solution is another flag (say
> >> PPTT_PROXIMITY_DOMAIN which would map to the D05 die) which could be used to
> >> find nodes with 1:1 correspondence. At that point we could add a fairly
> >> trivial patch to correct just the scheduler topology without affecting the
> >> rest of the system topology code.
> >
> > I think Morten asked already but isn't this the same end result we end
> > up having if we remove the DIE level if NUMA-within-package is detected
> > (instead of using the default_topology[]) and we create our own ARM64
> > domain hierarchy (with DIE level removed) through set_sched_topology()
> > accordingly ?
> >
> > Put it differently: do we really need to rely on another PPTT flag to
> > collect this information ?
> >
> > I can't merge code that breaks a platform with legitimate firmware
> > bindings.
>
> I think we really need another PPTT flag, from which we can get information
> about how to build a multi-core sched_domain. I think only cache-sharing information
> is not enough to get information about how to build a multi-core shced_domain.
>
> How about this? We assume the upper layer of the lowest layer to be multi-core layer.
> After that flag is added into ACPI specs, we add another patch to adapt to the change.
I'm not sure what you mean by upper layers of the lowest layer.
As I see it for non-numa-in-package system, the PPTT physical package
flag should define the MC domains, any levels above should be
represented in the DIE level, any level below should be ignored, except
the lowest level if we have SMT. If have SMT the lowest level in PPTT
should define the SMT domains.
For numa-in-package, the MC domains should be shrunk to match the NUMA
nodes and DIE is ignored.
next prev parent reply other threads:[~2018-03-01 14:19 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-13 0:59 [PATCH v6 00/12] Support PPTT for ARM64 Jeremy Linton
2018-01-13 0:59 ` [PATCH v6 01/12] drivers: base: cacheinfo: move cache_setup_of_node() Jeremy Linton
2018-01-15 12:23 ` Sudeep Holla
2018-01-13 0:59 ` [PATCH v6 02/12] drivers: base: cacheinfo: setup DT cache properties early Jeremy Linton
2018-01-15 12:33 ` Sudeep Holla
2018-01-15 16:07 ` Palmer Dabbelt
2018-01-16 21:26 ` Jeremy Linton
2018-01-17 18:08 ` Sudeep Holla
2018-01-18 17:36 ` Palmer Dabbelt
2018-01-16 21:07 ` Jeremy Linton
2018-01-17 18:20 ` Sudeep Holla
2018-01-17 18:51 ` Jeremy Linton
2018-01-18 10:14 ` Sudeep Holla
2018-01-19 23:27 ` Jeremy Linton
2018-01-13 0:59 ` [PATCH v6 03/12] cacheinfo: rename of_node to fw_unique Jeremy Linton
2018-01-15 12:36 ` Sudeep Holla
2018-01-13 0:59 ` [PATCH v6 04/12] arm64/acpi: Create arch specific cpu to acpi id helper Jeremy Linton
2018-01-15 13:46 ` Sudeep Holla
2018-01-13 0:59 ` [PATCH v6 05/12] ACPI/PPTT: Add Processor Properties Topology Table parsing Jeremy Linton
2018-01-15 14:58 ` Sudeep Holla
2018-01-16 20:55 ` Jeremy Linton
2018-01-17 17:58 ` Sudeep Holla
2018-01-15 15:48 ` Sudeep Holla
2018-01-16 20:22 ` Jeremy Linton
2018-01-17 18:00 ` Sudeep Holla
2018-01-13 0:59 ` [PATCH v6 06/12] ACPI: Enable PPTT support on ARM64 Jeremy Linton
2018-01-15 13:52 ` Sudeep Holla
2018-01-13 0:59 ` [PATCH v6 07/12] drivers: base cacheinfo: Add support for ACPI based firmware tables Jeremy Linton
2018-01-15 15:06 ` Sudeep Holla
2018-01-22 15:50 ` Greg KH
2018-01-22 21:14 ` Jeremy Linton
2018-01-23 0:11 ` Rafael J. Wysocki
2018-01-13 0:59 ` [PATCH v6 08/12] arm64: " Jeremy Linton
2018-01-15 13:54 ` Sudeep Holla
2018-01-13 0:59 ` [PATCH v6 09/12] ACPI/PPTT: Add topology parsing code Jeremy Linton
2018-01-13 0:59 ` [PATCH v6 10/12] arm64: topology: rename cluster_id Jeremy Linton
2018-01-13 0:59 ` [PATCH v6 11/12] arm64: topology: enable ACPI/PPTT based CPU topology Jeremy Linton
2018-01-25 12:15 ` Xiongfeng Wang
2018-01-25 15:56 ` Jeremy Linton
2018-01-26 4:21 ` Xiongfeng Wang
2018-02-23 11:02 ` Lorenzo Pieralisi
2018-02-24 3:05 ` Xiongfeng Wang
2018-02-25 6:17 ` vkilari
2018-03-01 14:19 ` Morten Rasmussen [this message]
2018-02-24 4:37 ` Jeremy Linton
2018-03-01 11:51 ` Morten Rasmussen
2018-01-13 0:59 ` [PATCH v6 12/12] ACPI: Add PPTT to injectable table list Jeremy Linton
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=20180301141903.GH4589@e105550-lin.cambridge.arm.com \
--to=morten.rasmussen@arm.com \
--cc=Jayachandran.Nair@cavium.com \
--cc=Jonathan.Zhang@cavium.com \
--cc=ahs3@redhat.com \
--cc=austinwc@codeaurora.org \
--cc=catalin.marinas@arm.com \
--cc=gregkh@linuxfoundation.org \
--cc=hanjun.guo@linaro.org \
--cc=jeremy.linton@arm.com \
--cc=jhugo@codeaurora.org \
--cc=juri.lelli@arm.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=mark.rutland@arm.com \
--cc=rjw@rjwysocki.net \
--cc=sudeep.holla@arm.com \
--cc=viresh.kumar@linaro.org \
--cc=vkilari@codeaurora.org \
--cc=wangxiongfeng2@huawei.com \
--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).