linux-kernel - Re: [RFC PATCH v10 3/8] 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] [day] [month] [year] [list]

Date: Tue, 4 Jun 2024 16:56:10 -0700
From: Ian Rogers <irogers@...gle.com>
To: Namhyung Kim <namhyung@...nel.org>
Cc: "Wang, Weilin" <weilin.wang@...el.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>, 
	"Hunter, Adrian" <adrian.hunter@...el.com>, Kan Liang <kan.liang@...ux.intel.com>, 
	"linux-perf-users@...r.kernel.org" <linux-perf-users@...r.kernel.org>, 
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "Taylor, Perry" <perry.taylor@...el.com>, 
	"Alt, Samantha" <samantha.alt@...el.com>, "Biggers, Caleb" <caleb.biggers@...el.com>
Subject: Re: [RFC PATCH v10 3/8] perf stat: Fork and launch perf record when
 perf stat needs to get retire latency value for a metric.

On Tue, Jun 4, 2024 at 3:41 PM Ian Rogers <irogers@...gle.com> wrote:
>
> On Tue, Jun 4, 2024 at 3:32 PM Namhyung Kim <namhyung@...nel.org> wrote:
> > Hmm.. I don't know if other metric already dealt with the scale like with
> > RAPL events.. If not, I think it's reasonable to add that to the metric
> > calculation.
> >
> > Ian, what do you think?
>
> Tbh, I don't understand the conversation and it looks like we're in
> the weeds. In metrics the scale/unit from the event aren't used - that
> is all events in a metric are the unscaled quantities unless something
> is broken.

As I understand the problem is that the retirement latencies are an
average and so fractional, assigning these to a u64 count loses the
fractional part. In the future we hope that the retirement latencies
will be directly read from an evsel. Should we scale up and then scale
down the retirement latency to avoid losing say 3 decimal places of
precision by multiplying and dividing by 1000? As the metrics read
unscaled values we'd need to change the formula. I'd prefer we didn't
do that and generally avoid making the retirement latency evsels
further special. So I think for now that means losing precision. We
can at least avoid some of the worst rounding by using "rint" when we
read the latency.

Thanks,
Ian