[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87le6nm20o.fsf@linux.intel.com>
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
Powered by blists - more mailing lists