From: Mark Rutland <mark.rutland@arm.com>
To: John Garry <john.garry@huawei.com>
Cc: "ak@linux.intel.com" <ak@linux.intel.com>,
Joakim Zhang <qiangqing.zhang@nxp.com>,
"suzuki.poulose@arm.com" <suzuki.poulose@arm.com>,
"peterz@infradead.org" <peterz@infradead.org>,
Will Deacon <will@kernel.org>, Linuxarm <linuxarm@huawei.com>,
"acme@kernel.org" <acme@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Zhangshaokun <zhangshaokun@hisilicon.com>,
"alexander.shishkin@linux.intel.com"
<alexander.shishkin@linux.intel.com>,
"mingo@redhat.com" <mingo@redhat.com>,
"james.clark@arm.com" <james.clark@arm.com>,
"namhyung@kernel.org" <namhyung@kernel.org>,
"jolsa@redhat.com" <jolsa@redhat.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"robin.murphy@arm.com" <robin.murphy@arm.com>,
Sudeep Holla <sudeep.holla@arm.com>
Subject: Re: [PATCH RFC 0/7] perf pmu-events: Support event aliasing for system PMUs
Date: Tue, 18 Feb 2020 18:13:31 +0000 [thread overview]
Message-ID: <20200218181331.GB9968@lakrids.cambridge.arm.com> (raw)
In-Reply-To: <cb004f43-b2a4-ae23-9fd3-0f70bd69701b@huawei.com>
On Tue, Feb 18, 2020 at 05:58:46PM +0000, John Garry wrote:
> On 18/02/2020 17:08, Mark Rutland wrote:
> > > > I also don't understand how a SoC ID makes things
> > > > any easier in this regard.
> > > It's doesn't necessarily make things easier in this regard. But using a SoC
> > > ID is an alternative to checking the SMMU_ID or the kernel driver having to
> > > know that it was a MMU-600 at all.
> > Using SOC_ID means that going forward, userspace needs to learn about
> > the integration details of each SoC in order to identify a component. As
> > you said:
> >
> > | As constantly checking what the SoC ID means throughout system components
> > | does not scale.
> >
> > ... and I think that equally applies to userspace in this case. Who knows how
> > many SoCs are going to have MMU-600?
> >
> > I also know that SOC_ID is going to be optional, and I think it's near-certain
> > that someone will end up producing two SoCs exposing the same ID.
>
> Wouldn't different SoCs having same SMC SOC_ID and revision be a (fixable)
> mistake in the SMC FW?
>
> And if it's not implemented, then no PMU events aliasing in perf tool for
> those uncore PMUs - nothing gets broken though and no regression. But I do
> understand your concern here.
>
> > For system PMUs, I'd rather the system PMU driver exposed some sort of
> > implementation ID. e.g. the SMMU_ID for SMMU. We can give that a generic name,
> > and mandate that where a driver exposes it, the format/meaning is defined in
> > the documentation for the driver.
>
> Then doesn't that per-PMU ID qualify as brittle and non-standard also?
Not in my mind; any instances of the same IP can have the same ID,
regardless of which SoC they're in. Once userspace learns about
device-foo-4000, it knows about it on all SoCs. That also means you can
support heterogeneous instances in the same SoC.
If a device varies so much on a SoC-by-SoC basis and or the driver has
no idea what to expose, it could be legitimate for the PMU driver to
expose the SoC ID as its PMU-specific ID, but I don't think we should
make that the common/only case.
> At least the SMC SoC ID is according to some standard.
>
> And typically most PMU HW would have no ID reg, so where to even get this
> identification info? Joakim Zhang seems to have this problem for the imx8
> DDRC PMU driver.
For imx8, the DT compat string or additional properties on the DDRC node
could be used to imply the id.
> > That can be namespace by driver, so e.g. keys would be smmu_sysfs_name/<id> and
> > ddrc_sysfs_name/<id>.
> >
> > > > > So even if it is solvable here, the kernel driver(s) will need to be
> > > > > reworked. And that is just solving one case in many.
> > > > PMU drivers will need to expose more information to userspace so that they
> > > > can be identified more precisely, yes. I wouldn't say they would need to be
> > > > "reworked".
> > > OK, so some combination of changes would still be required for the SMMU
> > > PMCG, IORT, and SMMUv3 drivers.
> > To expose the SMMU ID, surely that's just the driver?
>
> This case is complicated, like others I anticipate.
>
> So the SMMU PMCG HW has no ID register itself, and this idea relies on using
> the associated SMMUv3 IIDR in lieu. For that, we need to involve the IORT,
> SMMUv3, and SMMU PMCG drivers to create this linkage, and even then I still
> have my doubts on whether this is even proper.
Ok, I hadn't appreciated that the PMCG did not have an ID register
itself.
I think that the relationship between the SMMU and PMCG is a stronger
argument against using the SOC_ID. If the PMCGs in a system are
heterogeneous, then you must know the type of the specific instance.
> Please see https://lore.kernel.org/linux-iommu/1569854031-237636-1-git-send-email-john.garry@huawei.com/
> for reference.
>
> Or are there
> > implementations where the ID register is bogus and have to be overridden?
> >
>
> I will also note that perf tool PMU events framework relies today on
> generating a table of events aliases per CPU and matching based on that. If
> you want to totally disassociate a CPU or any SoC ID mapping, then this will
> require big perf tool rework.
I think that might be necessary, as otherwise we're going to back
ourselves into a corner by building what's simple now.
Thanks,
Mark.
next prev parent reply other threads:[~2020-02-18 18:13 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-24 14:34 [PATCH RFC 0/7] perf pmu-events: Support event aliasing for system PMUs John Garry
2020-01-24 14:34 ` [PATCH RFC 1/7] perf jevents: Add support for an extra directory level John Garry
2020-02-10 12:07 ` Jiri Olsa
2020-02-10 15:47 ` John Garry
2020-01-24 14:35 ` [PATCH RFC 2/7] perf vendor events arm64: Relocate hip08 core events John Garry
2020-01-24 14:35 ` [PATCH RFC 3/7] perf jevents: Add support for a system events PMU John Garry
2020-02-10 12:07 ` Jiri Olsa
2020-02-10 12:07 ` Jiri Olsa
2020-02-10 15:55 ` John Garry
2020-02-11 14:46 ` Jiri Olsa
2020-01-24 14:35 ` [PATCH RFC 4/7] perf pmu: Rename uncore symbols to include system PMUs John Garry
2020-02-10 12:07 ` Jiri Olsa
2020-02-10 15:44 ` John Garry
2020-02-11 14:43 ` Jiri Olsa
2020-02-11 15:36 ` John Garry
2020-02-12 12:08 ` Jiri Olsa
2020-01-24 14:35 ` [PATCH RFC 5/7] perf pmu: Support matching by sysid John Garry
2020-02-10 12:07 ` Jiri Olsa
2020-02-10 16:22 ` John Garry
2020-02-11 13:47 ` Jiri Olsa
2020-02-11 15:07 ` John Garry
2020-02-12 10:08 ` John Garry
2020-02-12 12:16 ` Jiri Olsa
2020-02-12 12:24 ` John Garry
2020-01-24 14:35 ` [PATCH RFC 6/7] perf vendor events arm64: Relocate uncore events for hip08 John Garry
2020-01-24 14:35 ` [PATCH RFC 7/7] perf vendor events arm64: Add hip08 SMMUv3 PMCG IMP DEF events John Garry
2020-02-11 15:24 ` [PATCH RFC 0/7] perf pmu-events: Support event aliasing for system PMUs James Clark
2020-02-11 15:41 ` John Garry
2020-02-18 12:57 ` Will Deacon
2020-02-18 13:24 ` John Garry
2020-02-18 13:39 ` Will Deacon
2020-02-18 16:19 ` John Garry
2020-02-18 17:08 ` Mark Rutland
2020-02-18 17:58 ` John Garry
2020-02-18 18:13 ` Mark Rutland [this message]
2020-02-19 1:55 ` Joakim Zhang
2020-02-19 8:44 ` John Garry
2020-02-19 12:40 ` Joakim Zhang
2020-02-19 14:28 ` John Garry
2020-02-19 8:50 ` John Garry
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=20200218181331.GB9968@lakrids.cambridge.arm.com \
--to=mark.rutland@arm.com \
--cc=acme@kernel.org \
--cc=ak@linux.intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=james.clark@arm.com \
--cc=john.garry@huawei.com \
--cc=jolsa@redhat.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxarm@huawei.com \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
--cc=qiangqing.zhang@nxp.com \
--cc=robin.murphy@arm.com \
--cc=sudeep.holla@arm.com \
--cc=suzuki.poulose@arm.com \
--cc=will@kernel.org \
--cc=zhangshaokun@hisilicon.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).