[RFT PATCH 0/7] perf tool: Support iostat for multiple platforms

[wangyushan]

On 1/27/2026 1:01 AM, Ian Rogers wrote:
> On Mon, Jan 26, 2026 at 4:35 AM Yushan Wang <wangyushan12 at huawei.com> wrote:
>> Currently, platform-specific iostat code for PMUs is implemented as a
>> common iostat callback interface and invoked based on what is being
>> built. This approach limits support for iostat across different types of
>> PMUs.
>>
>> Support of HiSilicon PCIe PMU iostat was raised at [1], which uses the
>> similar approach.
>>
>> To extend support of iostat across platforms, change common iostat
>> interface to framework to allow perf to probe PMU capabilities during
>> runtime and route iostat request to the correct PMU-specific functions.
>> Then HiSilicon PCIe PMU iostat is supported with the new framework.
>>
>> Request For Test:
>> Refactors has been made to x86 iostat to adapt the iostat framework, the
>> probe function that checks if there's any PMU's name contains 'x86-iio'
>> may not work properly, tests of that would be appreciated.
>>
>> [1] https://lore.kernel.org/all/4688a613-c94a-49b0-9d0f-09173c64082d@arm.com/
>>
>> Shiju Jose (2):
>>   perf-iostat: Extend iostat interface to support different iostat PMUs
>>   perf-iostat: Make x86 iostat compatible with new iostat framework
>>
>> Yicong Yang (1):
>>   perf-iostat: Enable iostat mode for HiSilicon PCIe PMU
>>
>> Yushan Wang (4):
>>   perf stat: Check color's length instead of the pointer
>>   perf stat: Save unnecessary print_metric() call
>>   perf-x86: iostat: Change iostat_prefix() to static
>>   perf-iostat: Support wilder wildcard-match for pmus
> Hi,
>
> Thanks for the changes! Given the iostat code is display code, it'd be
> great if we could avoid the arch directory usage. For example, I may
> record data on a machine with a HiSilicon PCIe PMU but then want to
> look at the data on an x86 laptop, as the code is under arch/arm64 it
> won't get built.Given the PMU name is unique, is it possible to put
> this code into tools/perf/util and determine whether to use it or not
> by seeing if the PMU is present by its name? I know that means
> refactoring the x86 code that hasn't done this.

Yes, iostat itself didn't do much more than rearrange the display
format. I can try to refactor that to the util directory, though x86
iostat may need even more testing :)

> A thought that is away from the iostat code and may simplify the code
> base is that we could introduce system PMU, rather than CPU, dependent
> metrics. Perhaps the iostat code could be replaced by a particular
> metric group like Default or TopdownL1, so `perf iostat` becomes
> something of a synonym for `perf stat -M iostat`. An example of what
> this may look like is (unmerged):
> https://lore.kernel.org/lkml/20260108191105.695131-34-irogers@google.com/
> where I introduce a memory bandwidth saturation metric dependent on
> uncore PMUs (either cbox or cha) on Intel. There is a metric
> "have_event" function that can be used to make a metric conditional.
> If you `perf stat record` a metric today and then look at the
> perf.data with `perf script --fields metric` (IIRC) then every metric
> that has the recorded events within it will be computed, although the
> code needs better testing, etc. I suspect the biggest downside to this
> approach is in how the output looks, but perhaps that can be tweaked.
> For example, the `ilist.py` command:
> https://web.git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/tree/tools/perf/python/ilist.py?h=perf-tools-next
> supports regular metrics.
Since iostat is a small sub-command with not many events involved,
it is great to have some events extracted as system metrics, like PCIe
bandwidth etc.

But the variety of bdf filtering and display may be difficult to adapt
to the way metric does it. What do you think if we leave the iostat as
is for now and maybe merge it to system metric infrastructure later?

> That said, I'm not against the changes, the arch directory usage, not
> using json metrics, etc. and this change is doing clean up, following
> existing patterns, etc. Sometimes the codebase has evolved but certain
> commands haven't kept up. I think `perf iostat` is a command like
> that.

And we are trying to make it follow up!

> Thanks,
> Ian

Thanks for the feedback!
Yushan
>>  tools/perf/arch/arm64/util/Build         |   1 +
>>  tools/perf/arch/arm64/util/hisi-iostat.c | 479 +++++++++++++++++++++++
>>  tools/perf/arch/x86/util/iostat.c        | 105 +++--
>>  tools/perf/builtin-script.c              |   2 +-
>>  tools/perf/util/iostat.c                 |  79 ++--
>>  tools/perf/util/iostat.h                 |  21 +-
>>  tools/perf/util/pmus.c                   |  12 +-
>>  tools/perf/util/pmus.h                   |   3 +
>>  tools/perf/util/stat-display.c           |   4 +-
>>  tools/perf/util/stat-shadow.c            |   4 +-
>>  10 files changed, 638 insertions(+), 72 deletions(-)
>>  create mode 100644 tools/perf/arch/arm64/util/hisi-iostat.c
>>
>> --
>> 2.33.0
>>