linux-kernel - Re: [PATCH v1 6/7] perf pmu-events: Remember the events and metrics table

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]

Date:   Sun, 8 Oct 2023 17:36:13 +0800
From:   Yang Jihong <yangjihong1@...wei.com>
To:     Ian Rogers <irogers@...gle.com>
CC:     Suzuki K Poulose <suzuki.poulose@....com>,
        Mike Leach <mike.leach@...aro.org>,
        James Clark <james.clark@....com>,
        Leo Yan <leo.yan@...aro.org>,
        John Garry <john.g.garry@...cle.com>,
        Will Deacon <will@...nel.org>,
        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>,
        Thomas Richter <tmricht@...ux.ibm.com>,
        Ravi Bangoria <ravi.bangoria@....com>,
        Kajol Jain <kjain@...ux.ibm.com>,
        Jing Zhang <renyu.zj@...ux.alibaba.com>,
        Kan Liang <kan.liang@...ux.intel.com>,
        <coresight@...ts.linaro.org>,
        <linux-arm-kernel@...ts.infradead.org>,
        <linux-perf-users@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v1 6/7] perf pmu-events: Remember the events and metrics
 table

Hello,

On 2023/10/8 13:49, Ian Rogers wrote:
> On Sat, Oct 7, 2023 at 8:39 PM Yang Jihong <yangjihong1@...wei.com> wrote:
>>
>> Hello,
>>
>> On 2023/10/7 10:13, Ian Rogers wrote:
>>> strcmp_cpuid_str performs regular expression comparisons. Avoid
>>> repeated computation of the table by remembering the table in a
>>> static.
>>>
>>> Signed-off-by: Ian Rogers <irogers@...gle.com>
>>> ---
>>>    tools/perf/pmu-events/jevents.py | 48 +++++++++++++++++++-------------
>>>    1 file changed, 28 insertions(+), 20 deletions(-)
>>>
>>> diff --git a/tools/perf/pmu-events/jevents.py b/tools/perf/pmu-events/jevents.py
>>> index fd009752b427..8d8d5088c53c 100755
>>> --- a/tools/perf/pmu-events/jevents.py
>>> +++ b/tools/perf/pmu-events/jevents.py
>>> @@ -978,28 +978,32 @@ int pmu_metrics_table__for_each_metric(const struct pmu_metrics_table *table,
>>>
>>>    const struct pmu_events_table *perf_pmu__find_events_table(struct perf_pmu *pmu)
>>>    {
>>> -        const struct pmu_events_table *table = NULL;
>>> -        char *cpuid = perf_pmu__getcpuid(pmu);
>>> +        static const struct pmu_events_table *table;
>>>            size_t i;
>>>
>>> -        /* on some platforms which uses cpus map, cpuid can be NULL for
>>> -         * PMUs other than CORE PMUs.
>>> -         */
>>> -        if (!cpuid)
>>> -                return NULL;
>>> -
>>> -        i = 0;
>>> -        for (;;) {
>>> -                const struct pmu_events_map *map = &pmu_events_map[i++];
>>> -                if (!map->arch)
>>> -                        break;
>>> -
>>> -                if (!strcmp_cpuid_str(map->cpuid, cpuid)) {
>>> -                        table = &map->event_table;
>>> -                        break;
>>> +        if (!table) {
>> If there is no matched table in pmu_events_map,
>> perf_pmu__find_events_table() will enter this branch for repeated search
>> each time.
>> Or do we need to use another variable to indicate whether the search has
>> been performed?
> 
> Agreed, the behavior will match the existing behavior. Longer term I
> want to remove this code. Do you have a scenario we should optimize
> for here?
> 

Yes, the CPU of the environment I'm using is "AuthenticAMD-15-6B-1" (not 
in the pmu_events_map).
As a result, the search is repeated every time.
(If `perf record true` is executed once, the search is repeated for 6 
times.)

This commit avoids repeated lookups to improve performance,
so if it's feasible, is it best to consider improving performance in 
this case as well?

Thanks,
Yang