[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87d17al60b.fsf@firstfloor.org>
Date: Fri, 01 Sep 2017 09:48:20 -0700
From: Andi Kleen <andi@...stfloor.org>
To: Milian Wolff <milian.wolff@...b.com>
Cc: linux-perf-users@...r.kernel.org,
Arnaldo Carvalho de Melo <acme@...nel.org>,
linux-kernel@...r.kernel.org, peterz@...radead.org
Subject: Re: broken cycle counts from perf record in frequency mode [Was: Re: deducing CPU clock rate over time from cycle samples]
Milian Wolff <milian.wolff@...b.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.
-Andi
Powered by blists - more mailing lists