Re: [PATCH 0/6] perf jevents: Add NVIDIA Tegra410 uncore PMU events and metrics

[Ian Rogers]

On Tue, Oct 20, 2026 at 3:15 PM Besar Wicaksono <bwicaksono@xxxxxxxxxx> wrote:
>
> > -----Original Message-----
> > From: Ian Rogers <irogers@xxxxxxxxxx>
> > Sent: Tuesday, October 20, 2026 8:33 PM
> > To: Arnaldo Carvalho de Melo <acme@xxxxxxxxxx>
> > Cc: James Clark <james.clark@xxxxxxxxxx>; Besar Wicaksono
> > <bwicaksono@xxxxxxxxxx>; namhyung@xxxxxxxxxx; linux-
> > tegra@xxxxxxxxxxxxxxx; linux-arm-kernel@xxxxxxxxxxxxxxxxxxx; linux-perf-
> > users@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; Vikram Sethi
> > <vsethi@xxxxxxxxxx>; Rich Wiley <rwiley@xxxxxxxxxx>; Sean Kelley
> > <skelley@xxxxxxxxxx>; Matt Ochs <mochs@xxxxxxxxxx>; Raj Joshi
> > <rajjoshi@xxxxxxxxxx>; Thierry Reding <treding@xxxxxxxxxx>; Jon Hunter
> > <jonathanh@xxxxxxxxxx>; john.garry@xxxxxxxxx; will@xxxxxxxxxx;
> > mike.leach@xxxxxxx; leo.yan@xxxxxxxxx; mark.rutland@xxxxxxx;
> > alexander.shishkin@xxxxxxxxxxxxxxx; jolsa@xxxxxxxxxx;
> > adrian.hunter@xxxxxxxxx; ctshao@xxxxxxxxxx
> > Subject: Re: [PATCH 0/6] perf jevents: Add NVIDIA Tegra410 uncore PMU
> > events and metrics
> >
> > External email: Use caution opening links or attachments
> >
> >
> > On Tue, Oct 20, 2026 at 12:15 PM Arnaldo Carvalho de Melo
> > <acme@xxxxxxxxxx> wrote:
> > >
> > > On Mon, Oct 19, 2026 at 06:23:16PM +0100, James Clark wrote:
> > > > On 19/10/2026 17:42, Besar Wicaksono wrote:
> > > > > Add event aliases and derived metrics for the NVIDIA Tegra410 uncore
> > > > > PMUs.
> > >
> > > > Reviewed-by: James Clark <james.clark@xxxxxxxxxx>
> > >
> > > Thanks, applied to perf-tools-next, for v7.4.
> >
> > Hi Arnaldo,
> >
> > can we not take these in v7.4 as there is unaddressed feedback:
> > https://lore.kernel.org/linux-perf-users/CAP-
> > 5=fWucvdYefDOL3Vn=O=YUPEXE+tngDDfPLv-
> > T5i3WkCJVA@xxxxxxxxxxxxxx/
> >
> > The specific problem is that the NVidia PMUs have adopted a convention
> > not supported by the perf tool of 'pmu_name_<socket>_rc_<num>'. rc
> > stands for root complex. What ends up happening is that aggregation is
> > broken as the json is claiming that pmu_name is the PMU's name while
> > the suffix perf_pmus code thinks pmu_name_<socket>_rc is the pmu name.
> > They've wrangled support via the json by claiming these are sys
> > events.
> >
> > We can either:
> > 1) support a new suffix convention of <num>_rc_<num>
> > 2) push back and ask the driver writers to name their PMU correctly as
> > defined in the ABI:
> > https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree
> > /Documentation/ABI/testing/sysfs-bus-event_source-devices
> >
> > If we do (1) then it would be nice if the support for that could be
> > contained in this patch series. In any case these events don't belong
> > in sys.
>
> Hi Ian,
>
> Could you elaborate more on why these uncore events don't belong in sys
> directory? Is it because T410 already has an entry in mapfile.csv?

I think the meaning of sys and system events has always been unclear.
The original patch series is:
https://lore.kernel.org/lkml/1607080216-36968-1-git-send-email-john.garry@xxxxxxxxxx/
However, since it isn't tied to a CPUID it should refer to things like
accelerator or network cards, not regular uncore PMUs.
The whole notion of sys events/metrics needs TLC as it doesn't make
sense for them to be in vendor directories if they aren't tied to
CPUIDs.

> I put them in sys so perf matches them to the PMU by its identifier ("Compat")
> rather than by the CPU, similar to hisilicon/hip09/sys and thead/yitian710/sys.

So it would be better to follow x86 as a model.

> For the aggregation concern, I replied on PATCH 4/6 and will look into
> it further.

So CT replied. The ABI document was created because the hex suffix
broke aggregation, which we fixed. As your reply details, cross-PMU
aggregation has been broken by your new suffix convention. With the
conventions we have, PMU names like i915 will match a name of just "i"
and ARM CPU names tend to be valid hex suffixes in things like
armv8_pmu_a53 - so we ignore suffixes on core PMUs. The distinction
between core and uncore PMUs in sysfs is also strange. Anyway, it
isn't perfect, but we documented it so that future PMUs wouldn't break
aggregation again - or if they did they can detail in the ABI and perf
code what the new additional convention is.

Ideally we wouldn't include anything fancy like physical addresses and
socket numbers in PMU names. Such information is already present in
/proc/iomem or the topology code, and the naming irregularities only
serve to break aggregation. To add detail to the PMU, use the caps
files. I don't think the perf tool should add new ways for every
vendor to aggregate, determine sockets, etc. It is bad enough we have
to carry fixes for ARM PMUs not honoring hot plugging and for the
cpumasks not being set up properly on Intel PMUs for sub-NUMA
clustering. Ideally, the perf tool could work in a user space
emulator—say, an x86 perf tool running under QEMU user emulation on an
ARM64 CPU. Special-casing CPU type and PMU logic defeats this goal.

Thanks,
Ian


> Thanks,
> Besar
>
> >
> > Thanks,
> > Ian
> >
> > > - Arnaldo