Received-SPF: pass (google.com: domain of linux-kernel+bounces-201577-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Precedence: bulk
MIME-Version: 1.0
References: <20240529064327.4080674-1-weilin.wang@intel.com>
 <20240529064327.4080674-4-weilin.wang@intel.com> <CAM9d7cgSwZ3PU3H9VNvxQakocEZ_CQEqB9M1o3xTMdJ7F1sufQ@mail.gmail.com>
 <CO6PR11MB56357F58D99B17CD08671A26EEFC2@CO6PR11MB5635.namprd11.prod.outlook.com>
 <CAM9d7cjbHzgfW2fKQkZ2=gtEMD9N5wG4xaWgPU+N-YvmfhXviQ@mail.gmail.com>
 <CO6PR11MB563511F1A6165F0F4B30C4DFEEF82@CO6PR11MB5635.namprd11.prod.outlook.com>
 <Zl-WCEhhxBtiGGhn@google.com> <CAP-5=fW41UxUDO-FSymMX_R5nEJDnV7FOjfhW5=XGCVj=TSYKQ@mail.gmail.com>
In-Reply-To: <CAP-5=fW41UxUDO-FSymMX_R5nEJDnV7FOjfhW5=XGCVj=TSYKQ@mail.gmail.com>
From: Ian Rogers <irogers@google.com>
Date: Tue, 4 Jun 2024 16:56:10 -0700
Message-ID: <CAP-5=fXtGcoXebwqMOqadK6Hkgx6Wa06UaNa3Ji9jrcW+9BWrQ@mail.gmail.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.
To: Namhyung Kim <namhyung@kernel.org>
Cc: "Wang, Weilin" <weilin.wang@intel.com>, Arnaldo Carvalho de Melo <acme@kernel.org>, 
	Peter Zijlstra <peterz@infradead.org>, Ingo Molnar <mingo@redhat.com>, 
	Alexander Shishkin <alexander.shishkin@linux.intel.com>, Jiri Olsa <jolsa@kernel.org>, 
	"Hunter, Adrian" <adrian.hunter@intel.com>, Kan Liang <kan.liang@linux.intel.com>, 
	"linux-perf-users@vger.kernel.org" <linux-perf-users@vger.kernel.org>, 
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "Taylor, Perry" <perry.taylor@intel.com>, 
	"Alt, Samantha" <samantha.alt@intel.com>, "Biggers, Caleb" <caleb.biggers@intel.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Jun 4, 2024 at 3:41=E2=80=AFPM Ian Rogers <irogers@google.com> wrot=
e:
>
> On Tue, Jun 4, 2024 at 3:32=E2=80=AFPM Namhyung Kim <namhyung@kernel.org>=
 wrote:
> > Hmm.. I don't know if other metric already dealt with the scale like wi=
th
> > 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