> 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
I always thought it just used the number of samples? > 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%. I don't think I've seen such a situation. Did you? BTW I'm not arguing against fixing it, but typically I just recommend to avoid frequency mode. The fast sampling at the beginning has caused a range of low level PMU bugs and it is hard to reason about because of its complex behavior. Also it has no protection against synchronizing with repeated patterns in the execution, which can cause bad shadowing effects. If you use the Intel event aliases they have all sensible periods set by default. -Andi
