Re: [PATCH 01/13] drm/msm: Remove obsolete perf infrastructure

[Rob Clark]

On Tue, Apr 21, 2026 at 5:41 PM Dmitry Baryshkov
<dmitry.baryshkov@xxxxxxxxxxxxxxxx> wrote:
>
> On Tue, Apr 21, 2026 at 01:48:40PM -0700, Rob Clark wrote:
> > On Tue, Apr 21, 2026 at 8:39 AM Dmitry Baryshkov
> > <dmitry.baryshkov@xxxxxxxxxxxxxxxx> wrote:
> > >
> > > On Tue, Apr 21, 2026 at 06:07:20AM -0700, Rob Clark wrote:
> > > > On Mon, Apr 20, 2026 at 4:49 PM Dmitry Baryshkov
> > > > <dmitry.baryshkov@xxxxxxxxxxxxxxxx> wrote:
> > > > >
> > > > > On Mon, Apr 20, 2026 at 03:25:23PM -0700, Rob Clark wrote:
> > > > > > Outside of a3xx, this was never really used.  And it low-key gets in the
> > > > > > way of the new perfcntr support (or at least it is confusing to have two
> > > > > > things called "perf").  So lets remove it.
> > > > > >
> > > > > > This drops the "perf" debugfs file.  But these days, nvtop is a better
> > > > > > option.  (Plus perfetto for newer gens.)
> > > > >
> > > > > Would it be possible to resurrect "perf" later? It was really useful.
> > > >
> > > > Nothing is impossible.. but I was having trouble naming things with
> > > > both old and new perf stuff in parallel.
> > >
> > > That why I wrote about resurrecting it later, once the new stuff is in.
> > >
> > > BTW: do you plan to get perf counters for a3xx-a5xx back? I remember
> > > that there was some issue with a2xx ABI.
> >
> > So current state on userspace side is that only a3xx/a4xx are missing
> > perfcntr support..  although it looks like we know the countable
> > enums, so probably not hard[*]
> >
> > In all cases, the existing userspace-only support will continue to
> > work.  The main reasons I omitted a2xx/a5xx on the kernel side are:
> >
> > a) Not really sure how to do the Makefile bits.. since they wouldn't
> > be using a6xx.xml.  In meson I can use a table (2d-array):
> >     https://gitlab.freedesktop.org/robclark/mesa/-/blob/fd/generate-perfcntrs/src/freedreno/registers/adreno/meson.build?ref_type=heads#L20
>
> I saw the comment in the commit. I'll take a quick look.
>
> > b) No good setup to test
>
> We probably need to figure this out...

More devices in CI would help, but I'm not really even sure of a great
way to automate testing of perfcntrs outside of some simple sanity
tests (like is the ALWAYS_COUNT based freq measurement something less
than fmax).

The best option I see is to just leave what works, and not introduce
features on older gens that may actually not work.  If there were
infinite hours in the day, sure there is a lot we could do.  But we
are still trying to close feature/perf/enablement gap with current and
recent hw.  I don't see how to continue to close that gap while also
bringing every new feature support to older hw that upstream supports
but android/downstream blob/kgsl has long dropped support for.

I'll accept patches, ofc, if someone is sufficiently motivated to
enable and test on older gens.  But otherwise, to close the gap we
need to run to where the ball is going, not where it was 10yrs ago.

> > c) They don't have IFPC
> >
> > They could ofc be added later.  The main urgency is a8xx, since I
> > don't want to add mesa perfcntr support without PERFCNTR_CONFIG (so
> > that we don't have an older-userspace, new-kernel permutation on
> > a8xx+).
>
> Sure.
>
> >
> > I don't remember about a2xx ABI issue.. but a2xx perfcntr stuff was
> > added after I was already busy with later gens.
>
> I might be completely mistaken, but I think the issue was that the
> kernel didn't reserve one of the counters for its own usage.

hmm, ok.. json has a "reserved" property for reserving counter(s) for
kernel usage.  We do use this on later gens.  Although it looks like
on a2xx there is only a single CP counter (which I'm guessing is the
one the kernel needs)

> >
> > BR,
> > -R
> >
> > [*] there are some counter groups that had some slightly different
> > config programming, like separate clear/enable regs.. which I haven't
> > dealt with yet.  For a6xx+ this only matters for some counter groups
> > (VBIF/GBIF, maybe GMU?) that userspace doesn't care as much about.
> > Idk if that was true for the earlier gens.  Eventually I'll add a6xx+
> > support for these counters, but there are a few other things to deal
> > with first.
> >
> > > > Is it really adding value
> > > > over nvtop?
>
> And I skipped this question. Yes, there is a value, when developing /
> performing early testing. Running tail is much easier than having an
> extra tool in the initramfs (we don't have nvtop recipe in the OE, maybe
> that should be changed).

could you monitor freq from devfreq or some clk related debugfs?

And yeah, getting nvtop in OE sounds like a good idea.

BR,
-R

> --
> With best wishes
> Dmitry