Re: [PATCH 2/3] perf: Reveal PMU type in fdinfo

[Ian Rogers]

On Tue, Nov 5, 2024 at 4:24 AM Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
>
> On Thu, Oct 31, 2024 at 10:39:44PM +0000, Chun-Tse Shao wrote:
> > It gives useful info on knowing which PMUs are reserved by this process.
> > Also add extra attributes which would be useful.
> >
> > ```
> > Testing cycles
> > $ ./perf stat -e cycles &
> > $ cat /proc/`pidof perf`/fdinfo/3
> > pos:    0
> > flags:  02000002
> > mnt_id: 16
> > ino:    3081
> > perf_event-orig_type:   0
> > perf_event-attr.config1:        0
> > perf_event-attr.config2:        0
> > perf_event-attr.config3:        0
> >
> > Testing L1-dcache-load-misses//
> > $ ./perf stat -e L1-dcache-load-misses &
> > $ cat /proc/`pidof perf`/fdinfo/3
> > pos:    0
> > flags:  02000002
> > mnt_id: 16
> > ino:    1072
> > perf_event-attr.type:   3
> > perf_event-attr.config: 65536
> > perf_event-attr.config1:        0
> > perf_event-attr.config2:        0
> > perf_event-attr.config3:        0
> > ```
>
> First time I hear about fdinfo.. How much of an ABI is this, and why
> this random selection of the perf_event_attr structure? What if someone
> else wants something and then we change it. Will this then break ABI?

Hi Peter,

There is a man page describing normal use of fdinfo:
https://man7.org/linux/man-pages/man5/proc_pid_fdinfo.5.html
I came across it wanting to implement a DRM PMU similar to the
(unmerged) hwmon PMU:
https://lore.kernel.org/all/20241022180623.463131-1-irogers@xxxxxxxxxx/
The DRM extension to fdinfo isn't described in the man page so I
propose it in these patches:
https://lore.kernel.org/all/20241101211830.1298073-4-irogers@xxxxxxxxxx/
Where DRM describes its fdinfo ABI here:
https://docs.kernel.org/gpu/drm-usage-stats.html
An example implementation is:
https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/tree/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c

> How much of an ABI is it?
I suspect that it is similar in this regard to anything in /proc, such
as /proc/pid/maps. /proc/pid/maps has been changed by things like
disabling the showing of "[stack:tid]" information, but generally it
stays the same. Adding information is obviously intended.

> Why this selection of perf_event_attr?
For the EBUSY warning perf_event-attr.type would suffice. I'd been
nagging for additional information for the sake of debugging. It gets
a little harder to print some values as they are in unions. These
values at least make a start.

> What if someone else wants something and then we change it. Will this then break ABI?
I don't think so. I can imagine lots of other information to be gained
through the API, like the hw_perf_event state.

Thanks,
Ian