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

[Ian Rogers]

On Thu, Jan 29, 2026 at 7:15 AM wangyushan <wangyushan12 at huawei.com> wrote:
>
>
>
> 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!

Hi Yushan, thanks for your effort on iostat! Did you have chance to
work on follow up?

Thanks,
Ian

> > 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
> >>
>