RE: [PATCH RFC v3 00/12] perf pmu-events: Support event aliasing for system PMUs
From: Joakim Zhang
Date: Tue May 12 2020 - 04:03:28 EST
> -----Original Message-----
> From: John Garry <john.garry@xxxxxxxxxx>
> Sent: 2020年5月7日 19:58
> To: peterz@xxxxxxxxxxxxx; mingo@xxxxxxxxxx; acme@xxxxxxxxxx;
> mark.rutland@xxxxxxx; alexander.shishkin@xxxxxxxxxxxxxxx;
> jolsa@xxxxxxxxxx; namhyung@xxxxxxxxxx
> Cc: will@xxxxxxxxxx; ak@xxxxxxxxxxxxxxx; linuxarm@xxxxxxxxxx;
> linux-kernel@xxxxxxxxxxxxxxx; Joakim Zhang <qiangqing.zhang@xxxxxxx>;
> irogers@xxxxxxxxxx; robin.murphy@xxxxxxx; zhangshaokun@xxxxxxxxxxxxx;
> linux-arm-kernel@xxxxxxxxxxxxxxxxxxx; John Garry <john.garry@xxxxxxxxxx>
> Subject: [PATCH RFC v3 00/12] perf pmu-events: Support event aliasing for
> system PMUs
>
> Currently event aliasing for only CPU and uncore PMUs is supported. In fact,
> only uncore PMUs aliasing is supported for when the uncore PMUs are fixed for
> a CPU, which may not always be the case for certain architectures.
>
> This series adds support for PMU event aliasing for system and other uncore
> PMUs which are not tied to a specific CPU. Or, more specifically, CPUs which
> not tied to those PMUs.
>
> For this, we introduce system event tables in generated pmu-events.c, which
> contain a per-SoC table of events of all its system PMUs. Each per-PMU event is
> matched by a "COMPAT" property.
>
> When creating aliases for PMUs, we treat core/uncore* and system PMUs
> differently:
>
> - For CPU PMU, we always match for the event mapfile based on the CPUID.
> This has not changed.
>
> - For an uncore or system PMU, we iterate through all the events in all
> the system PMU tables.
>
> Matches are based on the "COMPAT" property matching the PMU sysfs
> identifier contents, in /sys/bus/event_source/devices/<PMU>/identifier
>
> * uncore PMUs may also be matched by system PMUs event support.
>
> Initial reference support is also added for ARM SMMUv3 PMCG (Performance
> Monitor Event Group) PMU for HiSilicon hip08 platform with only a single event
> so far - see driver in drivers/perf/arm_smmuv3_pmu.c for that driver.
>
> Here is a sample output with this series on Huawei D06CS board:
>
> root@ubuntu:/# ./perf list
> [...]
>
> smmu v3 pmcg:
> smmuv3_pmcg.config_cache_miss
> [Configuration cache miss caused by transaction or(ATS or
> non-ATS)translation request. Unit: smmuv3_pmcg]
> smmuv3_pmcg.config_struct_access
> [Configuration structure access. Unit: smmuv3_pmcg]
> smmuv3_pmcg.cycles
> [Clock cycles. Unit: smmuv3_pmcg]
> smmuv3_pmcg.l1_tlb
> [SMMUv3 PMCG L1 TABLE transation. Unit: smmuv3_pmcg]
> smmuv3_pmcg.pcie_ats_trans_passed
> [PCIe ATS Translated Transaction passed through SMMU. Unit:
> smmuv3_pmcg]
> smmuv3_pmcg.pcie_ats_trans_rq
> [PCIe ATS Translation Request received. Unit: smmuv3_pmcg]
> smmuv3_pmcg.tlb_miss
> [TLB miss caused by incomingtransaction or (ATS or non-ATS)
> translation
> request. Unit: smmuv3_pmcg]
> smmuv3_pmcg.trans_table_walk_access
> [Translation table walk access. Unit: smmuv3_pmcg]
> smmuv3_pmcg.transaction
> [Transaction. Unit: smmuv3_pmcg]
>
>
> root@ubuntu:/# ./perf stat -v -e smmuv3_pmcg.l1_tlb sleep 1
> Using CPUID 0x00000000480fd010
> Using SYSID HIP08
> -> smmuv3_pmcg_200100020/event=0x8a/
> -> smmuv3_pmcg_200140020/event=0x8a/
> -> smmuv3_pmcg_100020/event=0x8a/
> -> smmuv3_pmcg_140020/event=0x8a/
> -> smmuv3_pmcg_200148020/event=0x8a/
> -> smmuv3_pmcg_148020/event=0x8a/
> smmuv3_pmcg.l1_tlb: 0 1001221690 1001221690
> smmuv3_pmcg.l1_tlb: 0 1001220090 1001220090
> smmuv3_pmcg.l1_tlb: 101 1001219660 1001219660
> smmuv3_pmcg.l1_tlb: 0 1001219010 1001219010
> smmuv3_pmcg.l1_tlb: 0 1001218360 1001218360
> smmuv3_pmcg.l1_tlb: 134 1001217850 1001217850
>
> Performance counter stats for 'system wide':
>
> 235 smmuv3_pmcg.l1_tlb
>
> 1.001263128 seconds time elapsed
>
> root@ubuntu:/#
>
> Support is also added for imx8mm DDR PMU.
>
> Series is here:
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c
> om%2Fhisilicon%2Fkernel-dev%2Ftree%2Fprivate-topic-perf-5.7-sys-pmu-event
> s-v3&data=02%7C01%7Cqiangqing.zhang%40nxp.com%7C7da833efd22b
> 439a131b08d7f27f53bc%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%
> 7C637244500996283083&sdata=a0W9Xk7gMLGtoU1VlcXAKF3x1eK%2BJ
> oCf0%2FfSAzxCnpU%3D&reserved=0
>
> Differences to v2:
> - fixups for imx8mm JSONs
> - fix for metrics being repeated per PMU
> - use sysfs__read_str()
> - fix typo in PMCG JSON
> - drop evsel fix, which someone else fixed
>
> Differences to v1:
> - Stop using SoC id and use a per-PMU identifier instead
> - Add metric group sys events support
> - This is a bit hacky
> - Add imx8mm DDR Perf support
> - Add fix for parse events sel
> - without it, I get this spewed for metric event:
>
> assertion failed at util/parse-events.c:1637
>
> Patches still need to be sent to support per-PMU identifer sysfs file
> in the kernel.
Hi John,
I have an aside question, do you have any idea? Thanks a lot!
For DDR PMU, I want to add bandwidth usage metric, but it depends on DDR controller clock frequency.
For example, we have i.MX8MM LPDDR4 board which DDR controller clock is 800MHZ, and i.MX8MM DDR4 board which DDR controller is 600MHZ, but the SoC is the same.
So they can share all JSON metrics with identifier "i.mx8mm", except bandwidth metric. If I add separate JOSN metrics files for identifier "i.mx8mm-lpddr4" and identifier "i.mx8mm-ddr4", then it's going to be very redundant, since most metrics are same just the identifier is different.
Do you know how perf tool handle such case?
Best Regards,
Joakim Zhang
> Thanks,
> John
>