Messages in this thread | | | Date | Mon, 27 Feb 2023 16:49:46 +0800 | Subject | Re: [RFC PATCH v1 0/4] HiSilicon Performance Monitor Control Unit | From | Jie Zhan <> |
| |
Please can anyone have a look at this PMCU patchset and provide some comments?
It is much related to the ARM PMU.
We are looking forward to the feedback.
Any relevant comments/questions, with respect to software or hardware design, use cases, coding, are welcome.
Kind regards,
Jie
On 06/02/2023 14:51, Jie Zhan wrote: > HiSilicon Performance Monitor Control Unit (PMCU) is a device that offloads > PMU accesses from CPUs, handling the configuration, event switching, and > counter reading of core PMUs on Kunpeng SoC. It facilitates fine-grained > and multi-PMU-event CPU profiling, in which scenario the current 'perf' > scheme may lose events or drop sampling frequency. With PMCU, users can > reliably obtain the data of up to 240 PMU events with the sample interval > of events down to 1ms, while the software overhead of accessing PMUs, as > well as its impact on target workloads, is reduced. > > This patchset contains the documentation, driver, and user perf tool > support to enable using PMCU with the 'perf_event' framework. > > Here are two key questions requested for comments: > > - How do we make it compatible with arm_pmu drivers? > > Hardware-wise, PMCU uses the existing core PMUs, so PMUs can be accessed > from CPU and PMCU simultaneously. The current hardware can't guarantee > mutual exclusive accesses. Hence, scheduling arm_pmu and PMCU events at > the same time may mess up the operation of PMUs, delivering incorrect > data for both events, e.g. unexpected events or sample periods. > Software-wise, we probably need to prevent the two types of events from > running at the same time, but currently there isn't a clear solution. > > - Currently we reply on a sysfs file for users to input event numbers. Is > there a better way to pass many events? > > The perf framework only allows three 64-bit config fields for custom PMU > configs. Obviously, this can't satisfy our need for passing many events > at a time. As an event number is 16-bit wide, the config fields can only > take up to 12 events at a time, or up to 192 events even if we do a > bitmap of events (and there are more than 192 available event numbers). > Hence, the current design takes an array of event numbers from a sysfs > file before starting profiling. However, this may go against the common > way to schedule perf events through perf commands. > > Jie Zhan (4): > docs: perf: Add documentation for HiSilicon PMCU > drivers/perf: hisi: Add driver support for HiSilicon PMCU > perf tool: Add HiSilicon PMCU data recording support > perf tool: Add HiSilicon PMCU data decoding support > > Documentation/admin-guide/perf/hisi-pmcu.rst | 183 +++ > Documentation/admin-guide/perf/index.rst | 1 + > drivers/perf/hisilicon/Kconfig | 15 + > drivers/perf/hisilicon/Makefile | 1 + > drivers/perf/hisilicon/hisi_pmcu.c | 1096 ++++++++++++++++++ > tools/perf/arch/arm/util/auxtrace.c | 61 + > tools/perf/arch/arm64/util/Build | 2 +- > tools/perf/arch/arm64/util/hisi-pmcu.c | 145 +++ > tools/perf/util/Build | 1 + > tools/perf/util/auxtrace.c | 4 + > tools/perf/util/auxtrace.h | 1 + > tools/perf/util/hisi-pmcu.c | 305 +++++ > tools/perf/util/hisi-pmcu.h | 19 + > 13 files changed, 1833 insertions(+), 1 deletion(-) > create mode 100644 Documentation/admin-guide/perf/hisi-pmcu.rst > create mode 100644 drivers/perf/hisilicon/hisi_pmcu.c > create mode 100644 tools/perf/arch/arm64/util/hisi-pmcu.c > create mode 100644 tools/perf/util/hisi-pmcu.c > create mode 100644 tools/perf/util/hisi-pmcu.h > > > base-commit: 830b3c68c1fb1e9176028d02ef86f3cf76aa2476
| |