Hi, I was using perf record to run various tests and I realized perf output was rather misleading.
If you sample a noploop program wich runs for 10s: $ perf record -F 1000 noploop 10 You expect a number of samples around: 10,000. Now if you divide the rate by 4: $ perf record -F 250 noploop 10 You expect around: 2500 samples Well, it turns out the printed count depends on the state of the whole system, not just noploop. The reason is that perf reports an estimate based on the number of bytes written to the buffer divided by the minimal sample size of 24 bytes. I think this is very confusing. It certainly got me. I understand that perf does not parse the samples it gets from the mmap'ed sampling buffer. Thus, it is not possible to get an accurate average sample size nor actual number of samples. What skews the estimate is the MMAP events (for the most part). The sampling buffer records *all* mmap()s happening in the system and this even if you are monitoring in per-thread mode. On a single-user workstation that may be fine, but on a loaded server you get lots of mmap events. And you don't care about most of them. This leads me to another point. For per-thread sampling, why do we need to record mmap() events happening *outside* of the process? I can understand the exception of kernel modules. Couldn't we restrict the event to those happening to the PID the event is attached to? ------------------------------------------------------------------------------ ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo _______________________________________________ perfmon2-devel mailing list perfmon2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
