linux-kernel - Re: [PATCH v2] perf stat: Introduce skippable evsels

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <c48515e6-6ba1-2c8e-7f84-869e227c5089@linux.intel.com>
Date:   Fri, 21 Apr 2023 13:10:54 -0400
From:   "Liang, Kan" <kan.liang@...ux.intel.com>
To:     Ian Rogers <irogers@...gle.com>,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...hat.com>
Cc:     Stephane Eranian <eranian@...gle.com>,
        Andi Kleen <ak@...ux.intel.com>,
        "Taylor, Perry" <perry.taylor@...el.com>,
        "Alt, Samantha" <samantha.alt@...el.com>,
        "Biggers, Caleb" <caleb.biggers@...el.com>,
        "Wang, Weilin" <weilin.wang@...el.com>,
        Edward <edward.baker@...el.com>,
        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>,
        Florian Fischer <florian.fischer@...q.space>,
        linux-perf-users@...r.kernel.org, linux-kernel@...r.kernel.org,
        "Yasin, Ahmad" <ahmad.yasin@...el.com>
Subject: Re: [PATCH v2] perf stat: Introduce skippable evsels

On 2023-04-21 11:49 a.m., Ian Rogers wrote:
>> Can we take a step back? Create a perf/json_metric or whatever branch,
>> fix all the issues thoroughly, and then merge to the mainline.
>>
>> I think the default of perf stat is frequently used by not only the
>> newbees but also the veterans. That could have a big user-visible impact.
>>
>> The 6.4 merge window is approaching. Can we at least revert the patches
>> for 6.4?
>>
>> Arnaldo, what do you think?
> Revert is a complete no go, we'd be reintroducing the bugs that are
> fixed and who will then fix those? How will they be fixed in any way
> other than how they've already been fixed? I've yet to see a
> description of a bug that isn't either:
> 1) an issue because the output formatting changed - the fix here is to
> use CSV or json output, using the hard coded metrics was a bug here
> anyway, not least as the metrics are wrong,
> 2) a pre-existing issue, such as hybrid is broken,
> 3) a non-issue, such as multiplexing on Skylake.
> That's not to say everything couldn't run better, which was the issue
> this patch was looking to address.

Sigh, we really need a clear design and definition regarding the default
of perf stat, especially what is included, what's the expected layout,
the forbidden. So everyone from the developers to the users is on the
same page. Could you please update the document for the default of perf
stat?

One more thing I want to point out is that the json metric may keep
changing. While the kernel metics (only includes the core part of the
json metric) is quite stable. For the default of perf stat, the kernel
metics should be a better choice.

Clarification: I'm not looking for reverting all the patches of the json
metrics in the perf-tool-next branch. The request is to revert the
patches which impact the default of perf stat. More specifically, the
patch 39 and 41.
https://lore.kernel.org/lkml/20230219092848.639226-40-irogers@google.com/

This is really a long discussion. I think we all express the arguments
clearly. Let's make the final decision and stop here.

Arnaldo? Peter? Ingo?

Could you please share your opinions?

Thanks,
Kan