SysadminNews

Raspberry Pi AXI PMU: measuring shared bus activity

On this page
  1. Pi 5 was already part of the first proposal
  2. Shared counters answer shared questions
  3. Read the event before calculating throughput

CPU activity alone cannot describe every transfer through a Raspberry Pi’s shared interconnect. The AXI PMU proposal would expose additional hardware counters through familiar perf tooling.

Conceptual shared monitor: CPU, display and I/O activity can contribute to a monitored interconnect event. The counter reports its selected scope, not automatic process ownership. Not exact Raspberry Pi wiring or a measured trace.
Conceptual shared monitor: CPU, display and I/O activity can contribute to a monitored interconnect event. The counter reports its selected scope, not automatic process ownership. Not exact Raspberry Pi wiring or a measured trace. Chart : PeopleAreGeek. Data source.
View full-size image

Pi 5 was already part of the first proposal

Ian Rogers’ August 11 v1 series contains two patches: the initial Broadcom AXI PMU driver and Raspberry Pi 5 support. It proposes sysfs event aliases and standard perf integration. Hardware validation on Pi 400 and Pi 5 is reported by the contributor, not performed by PeopleAreGeek.

The August 13 v7 revision retains Pi 5 in the second patch. It is misleading to describe that model simply as a future addition outside the series. Conversely, a submitted patch is not evidence of distribution availability. Our September 8 check of the v7.3-rc2 source did not find the proposed rpi_axi_pmu.c driver; this article does not announce it as shipped mainline support.

Shared counters answer shared questions

The cover places CPU work, display activity and I/O on a conceptual shared path into a monitor. A counter at such a point observes its selected event and bus scope, not a ready-made ownership label for each application. The drawing is not an exact SoC wiring diagram.

Suppose a counter rises while a video plays and a file copy runs. That observation alone cannot say which process caused every transfer, or whether those transfers explain an observed slowdown. A controlled comparison would hold one activity steady, change the other and compare the same event over equal intervals. Even then, correlation is evidence to investigate, not automatic proof of the bottleneck.

Read the event before calculating throughput

Check the event’s documented scope and unit scaling rather than labeling every raw count as bytes. Also keep monitor availability, firmware/device description and kernel configuration in the test record. A CPU assigned to read an uncore counter does not make the counter exclusive to work running on that CPU. These distinctions make the proposed integration useful without promising process-level attribution it has not established.

September 8: correct Raspberry Pi 5 scope in the first series; distinguish proposed perf integration from mainline delivery and shared counters from process attribution.