tools/perf/util/pmus.c | 107 +++++++++++++++++++++++++++++++++++++++-- 1 file changed, 102 insertions(+), 5 deletions(-)
When there are multiple PMUs differing by ordered suffixes only display one. This avoids repeated listing of events, in particular when there are 10s of uncore PMUs. This also helps speed the all PMU event tests. Before: ``` $ perf list ... uncore_imc_free_running_0/data_read/ [Kernel PMU event] uncore_imc_free_running_0/data_total/ [Kernel PMU event] uncore_imc_free_running_0/data_write/ [Kernel PMU event] uncore_imc_free_running_1/data_read/ [Kernel PMU event] uncore_imc_free_running_1/data_total/ [Kernel PMU event] uncore_imc_free_running_1/data_write/ [Kernel PMU event] ``` After: ``` $ perf list ... uncore_imc_free_running/data_read/ [Kernel PMU event] uncore_imc_free_running/data_total/ [Kernel PMU event] uncore_imc_free_running/data_write/ [Kernel PMU event] ``` The PMUs are sorted by name then suffix as a part of this change. Ian Rogers (3): perf pmus: Sort pmus by name then suffix perf pmus: Add scan that ignores duplicates, use for perf list perf pmus: Don't print PMU suffix in list tools/perf/util/pmus.c | 107 +++++++++++++++++++++++++++++++++++++++-- 1 file changed, 102 insertions(+), 5 deletions(-) -- 2.41.0.390.g38632f3daf-goog
On 11/07/2023 06:58, Ian Rogers wrote: > When there are multiple PMUs differing by ordered suffixes only > display one. This avoids repeated listing of events, in particular > when there are 10s of uncore PMUs. This also helps speed the all PMU > event tests. > > Before: > ``` > $ perf list > ... > uncore_imc_free_running_0/data_read/ [Kernel PMU event] > uncore_imc_free_running_0/data_total/ [Kernel PMU event] > uncore_imc_free_running_0/data_write/ [Kernel PMU event] > uncore_imc_free_running_1/data_read/ [Kernel PMU event] > uncore_imc_free_running_1/data_total/ [Kernel PMU event] > uncore_imc_free_running_1/data_write/ [Kernel PMU event] > ``` > > After: > ``` > $ perf list > ... > uncore_imc_free_running/data_read/ [Kernel PMU event] > uncore_imc_free_running/data_total/ [Kernel PMU event] > uncore_imc_free_running/data_write/ [Kernel PMU event] So with this change can we run something like: perf stat -e uncore_imc_free_running/data_read/ ? If so, does that match all PMUs whose name beings with "uncore_imc_free_running" (and give aggregate result for those PMUs)? Thanks, John > ``` > > The PMUs are sorted by name then suffix as a part of this change. > > Ian Rogers (3): > perf pmus: Sort pmus by name then suffix > perf pmus: Add scan that ignores duplicates, use for perf list > perf pmus: Don't print PMU suffix in list > > tools/perf/util/pmus.c | 107 +++++++++++++++++++++++++++++++++++++++-- > 1 file changed, 102 insertions(+), 5 deletions(-) >
On Tue, Jul 11, 2023 at 1:26 AM John Garry <john.g.garry@oracle.com> wrote:
>
> On 11/07/2023 06:58, Ian Rogers wrote:
> > When there are multiple PMUs differing by ordered suffixes only
> > display one. This avoids repeated listing of events, in particular
> > when there are 10s of uncore PMUs. This also helps speed the all PMU
> > event tests.
> >
> > Before:
> > ```
> > $ perf list
> > ...
> > uncore_imc_free_running_0/data_read/ [Kernel PMU event]
> > uncore_imc_free_running_0/data_total/ [Kernel PMU event]
> > uncore_imc_free_running_0/data_write/ [Kernel PMU event]
> > uncore_imc_free_running_1/data_read/ [Kernel PMU event]
> > uncore_imc_free_running_1/data_total/ [Kernel PMU event]
> > uncore_imc_free_running_1/data_write/ [Kernel PMU event]
> > ```
> >
> > After:
> > ```
> > $ perf list
> > ...
> > uncore_imc_free_running/data_read/ [Kernel PMU event]
> > uncore_imc_free_running/data_total/ [Kernel PMU event]
> > uncore_imc_free_running/data_write/ [Kernel PMU event]
>
> So with this change can we run something like:
>
> perf stat -e uncore_imc_free_running/data_read/
>
> ?
It is a long standing behavior of the event parser that we match the
numeric suffixes, so:
```
$ sudo perf stat -e uncore_imc_free_running/data_read/ -a sleep 1
Performance counter stats for 'system wide':
6,969.93 MiB uncore_imc_free_running/data_read/
1.001163027 seconds time elapsed
```
The "uncore_" at the beginning is also optional, I kind of wish the
"free_running" was too. The code doing this is:
https://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/tree/tools/perf/util/parse-events.y?h=perf-tools-next#n316
adding a * after the PMU name in:
asprintf(&pattern, "%s*", $1)
Then using fnmatch here:
https://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/tree/tools/perf/util/pmu.c?h=perf-tools-next#n1707
> If so, does that match all PMUs whose name beings with
> "uncore_imc_free_running" (and give aggregate result for those PMUs)?
Yep. As we're matching with a filename '*' glob then it will actually
potentially grab a bunch more. I think this should likely be made a
lot more precise.
The merging of the counters happens throughout the code, but it is set up here:
https://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/tree/tools/perf/util/stat.c?h=perf-tools-next#n559
I didn't write this behavior, it has pre-existed my contributions. I'm
hoping to change the perf list behavior as we're seeing large server
systems with getting on toward 100 PMUs, the events are replicated for
each one and the perf list and testing behaviors are somewhat
exploding in size.
Thanks,
Ian
> Thanks,
> John
>
> > ```
> >
> > The PMUs are sorted by name then suffix as a part of this change.
> >
> > Ian Rogers (3):
> > perf pmus: Sort pmus by name then suffix
> > perf pmus: Add scan that ignores duplicates, use for perf list
> > perf pmus: Don't print PMU suffix in list
> >
> > tools/perf/util/pmus.c | 107 +++++++++++++++++++++++++++++++++++++++--
> > 1 file changed, 102 insertions(+), 5 deletions(-)
> >
>
>>> ``` >>> $ perf list >>> ... >>> uncore_imc_free_running_0/data_read/ [Kernel PMU event] >>> uncore_imc_free_running_0/data_total/ [Kernel PMU event] >>> uncore_imc_free_running_0/data_write/ [Kernel PMU event] >>> uncore_imc_free_running_1/data_read/ [Kernel PMU event] >>> uncore_imc_free_running_1/data_total/ [Kernel PMU event] >>> uncore_imc_free_running_1/data_write/ [Kernel PMU event] >>> ``` >>> >>> After: >>> ``` >>> $ perf list >>> ... >>> uncore_imc_free_running/data_read/ [Kernel PMU event] >>> uncore_imc_free_running/data_total/ [Kernel PMU event] >>> uncore_imc_free_running/data_write/ [Kernel PMU event] >> So with this change can we run something like: >> >> perf stat -e uncore_imc_free_running/data_read/ >> >> ? > It is a long standing behavior of the event parser that we match the > numeric suffixes, so: I guess that I missed this as I assume that it would not handle more complex names, like hisi_sccl1_ddr3, which I was then interested in. > > ``` > $ sudo perf stat -e uncore_imc_free_running/data_read/ -a sleep 1 > > Performance counter stats for 'system wide': > > 6,969.93 MiB uncore_imc_free_running/data_read/ > > 1.001163027 seconds time elapsed > ``` > > The "uncore_" at the beginning is also optional, I kind of wish the > "free_running" was too. The code doing this is: > https://urldefense.com/v3/__https://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/tree/tools/perf/util/parse-events.y?h=perf-tools-next*n316__;Iw!!ACWV5N9M2RV99hQ!JduVayRc--qLXHsoXWTlMUsO4NBUoBnKQHqP2sx7VuwZiZzfVXaQZNBZuzO2Ie-twWQ1xu7nycBNFJ13LGk$ > adding a * after the PMU name in: > asprintf(&pattern, "%s*", $1) > Then using fnmatch here: > https://urldefense.com/v3/__https://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/tree/tools/perf/util/pmu.c?h=perf-tools-next*n1707__;Iw!!ACWV5N9M2RV99hQ!JduVayRc--qLXHsoXWTlMUsO4NBUoBnKQHqP2sx7VuwZiZzfVXaQZNBZuzO2Ie-twWQ1xu7nycBNa2_VzYE$ > >> If so, does that match all PMUs whose name beings with >> "uncore_imc_free_running" (and give aggregate result for those PMUs)? > Yep. As we're matching with a filename '*' glob then it will actually > potentially grab a bunch more. I think this should likely be made a > lot more precise. > > The merging of the counters happens throughout the code, but it is set up here: > https://urldefense.com/v3/__https://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/tree/tools/perf/util/stat.c?h=perf-tools-next*n559__;Iw!!ACWV5N9M2RV99hQ!JduVayRc--qLXHsoXWTlMUsO4NBUoBnKQHqP2sx7VuwZiZzfVXaQZNBZuzO2Ie-twWQ1xu7nycBNiVEZvEE$ > > I didn't write this behavior, it has pre-existed my contributions. I'm > hoping to change the perf list behavior as we're seeing large server > systems with getting on toward 100 PMUs, the events are replicated for > each one and the perf list and testing behaviors are somewhat > exploding in size. Sure, that is why I was advised PMU kernel drivers event names to be unique per PMU, so that we can add an event alias in a JSON and then kernel events are matched and removed from perf list. I suppose that your changes are an alternative to the problem of mushrooming kernel event list. Thanks, John
On Tue, Jul 11, 2023 at 8:24 AM John Garry <john.g.garry@oracle.com> wrote: > > > >>> ``` > >>> $ perf list > >>> ... > >>> uncore_imc_free_running_0/data_read/ [Kernel PMU event] > >>> uncore_imc_free_running_0/data_total/ [Kernel PMU event] > >>> uncore_imc_free_running_0/data_write/ [Kernel PMU event] > >>> uncore_imc_free_running_1/data_read/ [Kernel PMU event] > >>> uncore_imc_free_running_1/data_total/ [Kernel PMU event] > >>> uncore_imc_free_running_1/data_write/ [Kernel PMU event] > >>> ``` > >>> > >>> After: > >>> ``` > >>> $ perf list > >>> ... > >>> uncore_imc_free_running/data_read/ [Kernel PMU event] > >>> uncore_imc_free_running/data_total/ [Kernel PMU event] > >>> uncore_imc_free_running/data_write/ [Kernel PMU event] > >> So with this change can we run something like: > >> > >> perf stat -e uncore_imc_free_running/data_read/ > >> > >> ? > > It is a long standing behavior of the event parser that we match the > > numeric suffixes, so: > > I guess that I missed this as I assume that it would not handle more > complex names, like hisi_sccl1_ddr3, which I was then interested in. > > > > > ``` > > $ sudo perf stat -e uncore_imc_free_running/data_read/ -a sleep 1 > > > > Performance counter stats for 'system wide': > > > > 6,969.93 MiB uncore_imc_free_running/data_read/ > > > > 1.001163027 seconds time elapsed > > ``` > > > > The "uncore_" at the beginning is also optional, I kind of wish the > > "free_running" was too. The code doing this is: > > https://urldefense.com/v3/__https://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/tree/tools/perf/util/parse-events.y?h=perf-tools-next*n316__;Iw!!ACWV5N9M2RV99hQ!JduVayRc--qLXHsoXWTlMUsO4NBUoBnKQHqP2sx7VuwZiZzfVXaQZNBZuzO2Ie-twWQ1xu7nycBNFJ13LGk$ > > adding a * after the PMU name in: > > asprintf(&pattern, "%s*", $1) > > Then using fnmatch here: > > https://urldefense.com/v3/__https://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/tree/tools/perf/util/pmu.c?h=perf-tools-next*n1707__;Iw!!ACWV5N9M2RV99hQ!JduVayRc--qLXHsoXWTlMUsO4NBUoBnKQHqP2sx7VuwZiZzfVXaQZNBZuzO2Ie-twWQ1xu7nycBNa2_VzYE$ > > > >> If so, does that match all PMUs whose name beings with > >> "uncore_imc_free_running" (and give aggregate result for those PMUs)? > > Yep. As we're matching with a filename '*' glob then it will actually > > potentially grab a bunch more. I think this should likely be made a > > lot more precise. > > > > The merging of the counters happens throughout the code, but it is set up here: > > https://urldefense.com/v3/__https://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/tree/tools/perf/util/stat.c?h=perf-tools-next*n559__;Iw!!ACWV5N9M2RV99hQ!JduVayRc--qLXHsoXWTlMUsO4NBUoBnKQHqP2sx7VuwZiZzfVXaQZNBZuzO2Ie-twWQ1xu7nycBNiVEZvEE$ > > > > I didn't write this behavior, it has pre-existed my contributions. I'm > > hoping to change the perf list behavior as we're seeing large server > > systems with getting on toward 100 PMUs, the events are replicated for > > each one and the perf list and testing behaviors are somewhat > > exploding in size. > > Sure, that is why I was advised PMU kernel drivers event names to be > unique per PMU, so that we can add an event alias in a JSON and then > kernel events are matched and removed from perf list. > > I suppose that your changes are an alternative to the problem of > mushrooming kernel event list. Thanks John, yep this is going after that problem. Could I get a reviewed/acked/tested-by for these changes? Thanks, Ian > Thanks, > John
On 01/08/2023 18:39, Ian Rogers wrote: >>> I didn't write this behavior, it has pre-existed my contributions. I'm >>> hoping to change the perf list behavior as we're seeing large server >>> systems with getting on toward 100 PMUs, the events are replicated for >>> each one and the perf list and testing behaviors are somewhat >>> exploding in size. >> Sure, that is why I was advised PMU kernel drivers event names to be >> unique per PMU, so that we can add an event alias in a JSON and then >> kernel events are matched and removed from perf list. >> >> I suppose that your changes are an alternative to the problem of >> mushrooming kernel event list. > Thanks John, yep this is going after that problem. Could I get a > reviewed/acked/tested-by for these changes? I'll try to help. So we have: Before: ``` $ perf list ... uncore_imc_free_running_0/data_read/ [Kernel PMU event] uncore_imc_free_running_0/data_total/ [Kernel PMU event] uncore_imc_free_running_0/data_write/ [Kernel PMU event] uncore_imc_free_running_1/data_read/ [Kernel PMU event] uncore_imc_free_running_1/data_total/ [Kernel PMU event] uncore_imc_free_running_1/data_write/ [Kernel PMU event] ``` After: ``` $ perf list ... uncore_imc_free_running/data_read/ [Kernel PMU event] uncore_imc_free_running/data_total/ [Kernel PMU event] uncore_imc_free_running/data_write/ [Kernel PMU event] ``` How about keep listing uncore_imc_free_running_0 and the rest for perf list -v? Or something like that. I find that the perf tool has lots of veiled tricks in terms of usage and describing events available and how to use them. Thanks, John
© 2016 - 2026 Red Hat, Inc.