On Friday, September 1, 2017 6:48:20 PM CEST Andi Kleen wrote: > Milian Wolff <[email protected]> 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 | [email protected] | Senior Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel: +49-30-521325470 KDAB - The Qt Experts
smime.p7s
Description: S/MIME cryptographic signature
