With oprofile 0.9.8, the operf command below correctly produces the following
output on an Intel Core 2 Duo/RHEL 6.4 system when using too high of a
$ operf -e CPU_CLK_UNHALTED:20000 ./memcpyt 200000000
operf: Profiler started
Num iterations passed is 200000000
memcpyt starting with PID 2423
200000000 interations of memcpy(d+7.s+3,65) requires 10.016 seconds
* * * * WARNING: Profiling rate was throttled back by the kernel * * * *
The number of samples actually recorded is less than expected, but is
probably still statistically valid. Decreasing the sampling rate is the
best option if you want to avoid throttling.
The same operf command using current upstream oprofile (and 0.9.9) produces no
throttling message. But by comparing the number of samples with profile runs
using a lower sampling rate (i.e., count value >=100000 for CPU_CLK_UNHALTED),
I can see that the kernel must be throttling, because we're not collecting
enough samples for the given sampling rate.
Additionally, the opreport command should report when throttling has
occurred for the profile data being analyzed. This enhancement was made
post-0.9.8, but was broken at some point before 0.9.9 was released, so that
this informational message is also now missing from opreport.
This patch fixes both issues (and they were, indeed, separate bugs).
Signed-off-by: Maynard Johnson <firstname.lastname@example.org>