From: Milian Wolff <milian.wolff@kdab.com>
To: Andi Kleen <andi@firstfloor.org>
Cc: linux-perf-users@vger.kernel.org,
Arnaldo Carvalho de Melo <acme@kernel.org>,
linux-kernel@vger.kernel.org, peterz@infradead.org
Subject: Re: broken cycle counts from perf record in frequency mode [Was: Re: deducing CPU clock rate over time from cycle samples]
Date: Mon, 04 Sep 2017 16:35:15 +0200 [thread overview]
Message-ID: <1788258.9pJ1GNok8V@milian-kdab2> (raw)
In-Reply-To: <87d17al60b.fsf@firstfloor.org>
[-- Attachment #1: Type: text/plain, Size: 1953 bytes --]
On Friday, September 1, 2017 6:48:20 PM CEST Andi Kleen wrote:
> Milian Wolff <milian.wolff@kdab.com> writes:
> > do you have any input on this issue? I really wonder why noone else is
> > complaining about the frequency mode being unreliable or right out broken
> > in many situations. Since it's the default mode, I think this urgently
> > needs to be investigated - it makes perf unusable for a large group of
> > users who want to use it but don't know about `-c N` as a workaround...
>
> It's likely related due to the frequency algorithm starting with 0. So
> at the beginning the samples are very fast (like 1 cycle) and likely
> something breaks down in perf or your frequency calculation for very
> short samples.
>
> Also for inherited events this happens on every fork. If you
> trace fork events too you'll likely see it correlated.
> If you use -a and disable inheritance (no-inherit=1) it will
> also likely be only at the beginning.
>
> However I fail to see what it would actually break. The frequency
> just needs to be roughly accurate over the whole measurement
> period to get good sampling coverage. But there's nothing
> in the profile that uses the actual frequency. It's just a means
> to get samples, not a measurement by itself.
The cycle value gets associated with a sample via it's period value, which is
used by `perf report` in the analysis. If I get a single "broken" sample with
a cycle count of, say 1E14 and then a million other samples, each with "sane"
cycle counts of let's say 1E5, then the one broken sample will hold 50% of the
total amount of measured cycles. So perf report will show that the function
where the broken sample points to will have a cost of 50%.
To me, this is clearly a really big issue. Don't you think so too?
Thanks
--
Milian Wolff | milian.wolff@kdab.com | Senior Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt Experts
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 3826 bytes --]
next prev parent reply other threads:[~2017-09-04 14:35 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-17 19:07 deducing CPU clock rate over time from cycle samples Milian Wolff
2017-06-18 4:22 ` Andi Kleen
2017-06-18 19:53 ` Milian Wolff
2017-08-28 14:08 ` broken cycle counts from perf record in frequency mode [Was: Re: deducing CPU clock rate over time from cycle samples] Milian Wolff
2017-08-28 14:40 ` Milian Wolff
2017-08-28 17:28 ` Andi Kleen
2017-09-01 10:34 ` Milian Wolff
2017-09-01 16:48 ` Andi Kleen
2017-09-04 14:35 ` Milian Wolff [this message]
2017-09-05 3:40 ` Andi Kleen
2017-09-05 12:26 ` Milian Wolff
Reply instructions:
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1788258.9pJ1GNok8V@milian-kdab2 \
--to=milian.wolff@kdab.com \
--cc=acme@kernel.org \
--cc=andi@firstfloor.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=peterz@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).