linux-kernel - Re: [RFC PATCH v4 2/6] perf stat: Fork and launch perf record when perf stat needs to get retire latency value for a metric.

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: Tue, 12 Mar 2024 17:03:19 -0700
From: Andi Kleen <ak@...ux.intel.com>
To: weilin.wang@...el.com
Cc: Namhyung Kim <namhyung@...nel.org>,  Ian Rogers <irogers@...gle.com>,
  Arnaldo Carvalho de Melo <acme@...nel.org>,  Peter Zijlstra
 <peterz@...radead.org>,  Ingo Molnar <mingo@...hat.com>,  Alexander
 Shishkin <alexander.shishkin@...ux.intel.com>,  Jiri Olsa
 <jolsa@...nel.org>,  Adrian Hunter <adrian.hunter@...el.com>,  Kan Liang
 <kan.liang@...ux.intel.com>,  linux-perf-users@...r.kernel.org,
  linux-kernel@...r.kernel.org,  Perry Taylor <perry.taylor@...el.com>,
  Samantha Alt <samantha.alt@...el.com>,  Caleb Biggers
 <caleb.biggers@...el.com>
Subject: Re: [RFC PATCH v4 2/6] perf stat: Fork and launch perf record when
 perf stat needs to get retire latency value for a metric.

weilin.wang@...el.com writes:

> From: Weilin Wang <weilin.wang@...el.com>
>
> When retire_latency value is used in a metric formula, perf stat would fork a
> perf record process with "-e" and "-W" options. Perf record will collect
> required retire_latency values in parallel while perf stat is collecting
> counting values.

How does that work when the workload is specified on the command line?
The workload would run twice? That is very inefficient and may not
work if it's a large workload.

The perf tool infrastructure is imho not up to the task of such
parallel collection.

Also it won't work for very long collections because you will get a
very large perf.data. Better to use a pipeline.

I think it would be better if you made it a separate operation that can
generate a file that is then consumed by perf stat. This is also more efficient
because often the calibration is only needed once. And it's all under
user control so no nasty surprises.

-Andi