LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Ian Rogers <firstname.lastname@example.org>
To: Rob Herring <email@example.com>
Cc: "firstname.lastname@example.org" <email@example.com>,
Subject: Re: [PATCH 1/3] libperf: Add processing to scale the counters obtained during the read() system call when multiplexing
Date: Tue, 7 Sep 2021 16:59:42 -0700 [thread overview]
Message-ID: <CAP-5=fW_g9JHKWQoNiwNeSN8MjJ1OA7qLb3JD3ErEi1be4DEiQ@mail.gmail.com> (raw)
On Tue, Aug 31, 2021 at 5:26 AM Rob Herring <firstname.lastname@example.org> wrote:
> On Tue, Aug 24, 2021 at 5:12 AM email@example.com
> <firstname.lastname@example.org> wrote:
> > Hi, Rob
> > > On Fri, Aug 20, 2021 at 06:39:06PM +0900, Shunsuke Nakamura wrote:
> > > > perf_evsel__read() scales counters obtained by RDPMC during multiplexing, but
> > > > does not scale counters obtained by read() system call.
> > > >
> > > > Add processing to perf_evsel__read() to scale the counters obtained during the
> > > > read() system call when multiplexing.
> > >
> > > Which one is right though? Changing what read() returns could break
> > > users, right? Or are you implying that the RDPMC path is correct and
> > > read() was not. More likely the former case since I wrote the latter.
> > perf_evsel__read() returns both the count obtained by RDPMC and the count obtained
> > by the read() system call when multiplexed with RDPMC enabled.
> > That is, there is a mix of scaled and unscaled values.
> > As Rob says, when this patch is applied, rescaling the count obtained from
> > perf_evsel__read() during multiplexing will break the count.
> > I think the easiest solution is to change the value you get from RDPMC to not scale
> > and let the user scale it, but I thought it would be a little inconvenient.
> Agreed, unless someone else has an opinion. It would be good to do the
> scaling in libperf with the optimized math op, but I assume there's
> some reason the user may need unscaled values?
Hi, something I've mentioned on other threads  is that running may
be zero due to multiplexing but enabled be greater. This can lead to a
divide by zero when scaling. Giving the ratio to the caller gives more
information - I may be misunderstanding this thread, apologies if so.
next prev parent reply other threads:[~2021-09-07 23:59 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-20 9:39 [PATCH 0/3] libperf: Add support for scaling counters obtained from the read() system call during multiplexing Shunsuke Nakamura
2021-08-20 9:39 ` [PATCH 1/3] libperf: Add processing to scale the counters obtained during the read() system call when multiplexing Shunsuke Nakamura
2021-08-23 20:12 ` Rob Herring
2021-08-24 10:11 ` nakamura.shun
2021-08-31 8:58 ` nakamura.shun
2021-08-31 12:26 ` Rob Herring
2021-09-07 23:59 ` Ian Rogers [this message]
2021-09-17 8:04 ` nakamura.shun
2021-08-20 9:39 ` [PATCH 2/3] libperf tests: Fix verbose printing Shunsuke Nakamura
2021-08-23 20:26 ` Rob Herring
2021-08-24 18:06 ` Arnaldo Carvalho de Melo
2021-08-20 9:39 ` [PATCH 3/3] libperf tests: Add test_stat_multiplexing test Shunsuke Nakamura
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--subject='Re: [PATCH 1/3] libperf: Add processing to scale the counters obtained during the read() system call when multiplexing' \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).