[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <cd5814af-8ab0-6ab9-9b3c-b5081e54f199@oracle.com>
Date: Tue, 11 Jul 2023 16:24:22 +0100
From: John Garry <john.g.garry@...cle.com>
To: Ian Rogers <irogers@...gle.com>
Cc: Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...hat.com>,
Arnaldo Carvalho de Melo <acme@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
Jiri Olsa <jolsa@...nel.org>,
Namhyung Kim <namhyung@...nel.org>,
Adrian Hunter <adrian.hunter@...el.com>,
Kan Liang <kan.liang@...ux.intel.com>,
Ravi Bangoria <ravi.bangoria@....com>,
linux-perf-users@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1 0/3] perf list: Remove duplicate PMUs
>>> ```
>>> $ 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
Powered by blists - more mailing lists