With oprofile 0.9.8, the operf command below produces the following output on an Intel Core 2 Duo/RHEL 6.4 system:
[maynard@oc3431575272 test-stuff]$ operf -e CPU_CLK_UNHALTED:20000 ./memcpyt 200000000 operf: Profiler started Num iterations passed is 200000000 memcpyt starting with PID 2423 source_address: 7fff689b7003 dest_address: 7fff689b5007 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. Profiling done.
The same operf command using current upstream oprofile 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.