Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1726120

Re: broken cycle counts from perf record in frequency mode [Was: Re: deducing CPU clock rate over time from cycle samples]

Show all headers | View raw

[Multipart message — attachments visible in raw view] - view raw

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

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

broken cycle counts from perf record in frequency mode [Was: Re: deducing CPU clock rate over time from cycle samples] Milian Wolff <milian.wolff@kdab.com> - 2017-08-28 16:10 +0200
  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@kdab.com> - 2017-08-28 16:50 +0200
    Re: broken cycle counts from perf record in frequency mode [Was: Re:  deducing CPU clock rate over time from cycle samples] Andi Kleen <andi@firstfloor.org> - 2017-08-28 19:30 +0200
      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@kdab.com> - 2017-09-01 12:40 +0200
        Re: broken cycle counts from perf record in frequency mode [Was: Re: deducing CPU clock rate over time from cycle samples] Andi Kleen <andi@firstfloor.org> - 2017-09-01 18:50 +0200
          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@kdab.com> - 2017-09-04 16:40 +0200
            Re: broken cycle counts from perf record in frequency mode [Was: Re:  deducing CPU clock rate over time from cycle samples] Andi Kleen <andi@firstfloor.org> - 2017-09-05 05:50 +0200
              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@kdab.com> - 2017-09-05 14:30 +0200

csiph-web