lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAP-5=fU4c+kU0OYbPp0andZW33tHiewyoxkvXbrU36EyLKKZ2A@mail.gmail.com>
Date:   Tue, 1 Aug 2023 10:39:53 -0700
From:   Ian Rogers <irogers@...gle.com>
To:     John Garry <john.g.garry@...cle.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

On Tue, Jul 11, 2023 at 8:24 AM John Garry <john.g.garry@...cle.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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ