perf-trace: improving ioctl details

perf-trace: improving ioctl details

[David Ahern]

Hi Arnaldo, Namhyung:

I have a couple of patches to perf-trace to improve the details on ioctl
calls. The first one tracks stats by individual filenames, and for the
summary output prints the ioctl stats per filename.

The second patch improves the output for the _IOC_NR element of the op
argument. For flexibility across kernel versions and drivers, it adds
the ability to read input files that contain the conversion from number
to human readable name. The files (if the option is set) are parsed at
start up. In addition to the summary, the cache is also used to improve
the readability of each ioctl line.

Questions for you:
1. is such an open ended design acceptable for perf-trace?

2. if yes, is there any preference on file format (json, yaml,
key-value, ...)?

Thanks,
David

Re: perf-trace: improving ioctl details

[Arnaldo Melo]

On February 18, 2026 2:09:26 PM GMT-03:00, David Ahern <dsahern@kernel.org> wrote:
>Hi Arnaldo, Namhyung:
>
>I have a couple of patches to perf-trace to improve the details on ioctl
>calls. The first one tracks stats by individual filenames, and for the
>summary output prints the ioctl stats per filename.
>

Looks interesting!


>The second patch improves the output for the _IOC_NR element of the op
>argument. For flexibility across kernel versions and drivers, it adds
>the ability to read input files that contain the conversion from number
>to human readable name. The files (if the option is set) are parsed at
>start up. In addition to the summary, the cache is also used to improve
>the readability of each ioctl line.
>
>Questions for you:
>1. is such an open ended design acceptable for perf-trace?

Is it lazy, i.e. only when needed this cache/table gets loaded? 

>
>2. if yes, is there any preference on file format (json, yaml,
>key-value, ...)?

We already have JSON parsing infra, so probably that is better? 

Great to see you contributing to perf again! 

- Arnaldo

>
>Thanks,
>David

- Arnaldo

Re: perf-trace: improving ioctl details

[Namhyung Kim]

Hi David!

On Wed, Feb 18, 2026 at 04:34:33PM -0300, Arnaldo Melo wrote:
> 
> 
> On February 18, 2026 2:09:26 PM GMT-03:00, David Ahern <dsahern@kernel.org> wrote:
> >Hi Arnaldo, Namhyung:
> >
> >I have a couple of patches to perf-trace to improve the details on ioctl
> >calls. The first one tracks stats by individual filenames, and for the
> >summary output prints the ioctl stats per filename.
> >
> 
> Looks interesting!

Indeed.

> 
> 
> >The second patch improves the output for the _IOC_NR element of the op
> >argument. For flexibility across kernel versions and drivers, it adds
> >the ability to read input files that contain the conversion from number
> >to human readable name. The files (if the option is set) are parsed at
> >start up. In addition to the summary, the cache is also used to improve
> >the readability of each ioctl line.
> >
> >Questions for you:
> >1. is such an open ended design acceptable for perf-trace?
> 
> Is it lazy, i.e. only when needed this cache/table gets loaded? 

I think it's ok.  But I'm curious what's the actual usecases.. do you
want it for testing kernels and drivers?  I guess we can have a default
table for regular users and provide the option for kernel developers.

> 
> >
> >2. if yes, is there any preference on file format (json, yaml,
> >key-value, ...)?
> 
> We already have JSON parsing infra, so probably that is better? 

JSON should be fine, although it's a bit verbose.  I'm fine with plain
KEY=VALUE format too if it's really a simple mapping.

> 
> Great to see you contributing to perf again! 

+1

Thanks,
Namhyung

Re: perf-trace: improving ioctl details

[David Ahern]

Sorry for the delayed response; my time seems to evaporate these days.

On 2/19/26 11:49 AM, Namhyung Kim wrote:
>>> Questions for you:
>>> 1. is such an open ended design acceptable for perf-trace?
>>
>> Is it lazy, i.e. only when needed this cache/table gets loaded? 
> 
> I think it's ok.  But I'm curious what's the actual usecases.. do you
> want it for testing kernels and drivers?  I guess we can have a default
> table for regular users and provide the option for kernel developers.

The idea is that ioctl is a very open ended and overloaded uapi, and I
wanted better granularity on how that time was spent. The breakdown by
filename and NR is one level; improving human readability of the NR is
another.

For the latter, if you look at tools/perf/trace/beauty/ioctl.c, you can
see how human readability for NRs has been improved for specific
subsystems tty, drm, pcm, kvm, ... (the table in ioctl__scnprintf_cmd),
but that design is not going to scale for all of the devices and
drivers, especially those with dynamic major numbers. Allowing runtime
loading of files seemed like an easy way to accommodate the range of
ioctl users in a flexible way. (though it too has limitations given the
multiplexing on specific NRs)

> 
>>
>>>
>>> 2. if yes, is there any preference on file format (json, yaml,
>>> key-value, ...)?
>>
>> We already have JSON parsing infra, so probably that is better? 

json is used for the PMU files, but it seems to be used only for code
generation (pmu-events/pmu-events.c) at build time, not run time loading
which I was targeting. Hence the question on format.

> 
> JSON should be fine, although it's a bit verbose.  I'm fine with plain
> KEY=VALUE format too if it's really a simple mapping.

key=value format is what I have now. The only awkwardness is a header to
declare the filename it corresponds to and then a further complication
is the need for a wildcard format as there are examples that have
multiple instances (e.g., /dev/infiniband/uverbs*).

> 
>>
>> Great to see you contributing to perf again! 
> 
> +1
> 

Thanks. perf-trace code has changed quite a bit over the past 10 years.

Re: perf-trace: improving ioctl details

[Namhyung Kim]

On Fri, Feb 20, 2026 at 08:33:01AM -0700, David Ahern wrote:
> Sorry for the delayed response; my time seems to evaporate these days.

:)

> 
> On 2/19/26 11:49 AM, Namhyung Kim wrote:
> >>> Questions for you:
> >>> 1. is such an open ended design acceptable for perf-trace?
> >>
> >> Is it lazy, i.e. only when needed this cache/table gets loaded? 
> > 
> > I think it's ok.  But I'm curious what's the actual usecases.. do you
> > want it for testing kernels and drivers?  I guess we can have a default
> > table for regular users and provide the option for kernel developers.
> 
> The idea is that ioctl is a very open ended and overloaded uapi, and I
> wanted better granularity on how that time was spent. The breakdown by
> filename and NR is one level; improving human readability of the NR is
> another.
> 
> For the latter, if you look at tools/perf/trace/beauty/ioctl.c, you can
> see how human readability for NRs has been improved for specific
> subsystems tty, drm, pcm, kvm, ... (the table in ioctl__scnprintf_cmd),
> but that design is not going to scale for all of the devices and
> drivers, especially those with dynamic major numbers. Allowing runtime
> loading of files seemed like an easy way to accommodate the range of
> ioctl users in a flexible way. (though it too has limitations given the
> multiplexing on specific NRs)

I see.  So would your patch match ioctl by name instead of number?  I'm
curious if we can do the same in the beautifier code to handle dynamic
numbers.. maybe after checking static numbers.

> 
> > 
> >>
> >>>
> >>> 2. if yes, is there any preference on file format (json, yaml,
> >>> key-value, ...)?
> >>
> >> We already have JSON parsing infra, so probably that is better? 
> 
> json is used for the PMU files, but it seems to be used only for code
> generation (pmu-events/pmu-events.c) at build time, not run time loading
> which I was targeting. Hence the question on format.
> 
> > 
> > JSON should be fine, although it's a bit verbose.  I'm fine with plain
> > KEY=VALUE format too if it's really a simple mapping.
> 
> key=value format is what I have now. The only awkwardness is a header to
> declare the filename it corresponds to and then a further complication
> is the need for a wildcard format as there are examples that have
> multiple instances (e.g., /dev/infiniband/uverbs*).

I think it's ok as we have config files with this format:

  [section]
    # comment
    key = value

> 
> > 
> >>
> >> Great to see you contributing to perf again! 
> > 
> > +1
> > 
> 
> Thanks. perf-trace code has changed quite a bit over the past 10 years.
 
Yes, it does. :)

Thanks,
Namhyung