c - OProfile 警告 'dropping hyperspace sample' 是什么意思？

Question

当使用统计执行分析器 OProfile 可视化我的 C 应用程序的调用图配置文件时，它多次包含以下警告。警告对我来说相当神秘:

warning: dropping hyperspace sample at offset 1af9 >= 2be8 for binary /home/myuser/mybinary

我在这样的 Xen 虚拟化环境中使用 OProfile:

modprobe oprofile timer=1
opcontrol --no-vmlinux
opcontrol --start
(wait for profiling data to accumulate)
opcontrol --stop
opreport --session-dir=/var/lib/oprofile --exclude-dependent --demangle=smart \
--symbols /home/myuser/mybinary --callgraph

最后一条命令的完整输出是:

Overflow stats not available
CPU: CPU with timer interrupt, speed 0 MHz (estimated)
Profiling through timer interrupt
warning: dropping hyperspace sample at offset 84d0 >= 79a0 for binary /home/myuser/mybinary
warning: dropping hyperspace sample at offset 7ac0 >= 79a0 for binary /home/myuser/mybinary
warning: dropping hyperspace sample at offset 7d90 >= 79a0 for binary /home/myuser/mybinary
warning: dropping hyperspace sample at offset 7ac0 >= 79a0 for binary /home/myuser/mybinary
warning: dropping hyperspace sample at offset 7d90 >= 79a0 for binary /home/myuser/mybinary
warning: dropping hyperspace sample at offset 8210 >= 79a0 for binary /home/myuser/mybinary
samples  %        symbol name
-------------------------------------------------------------------------------

之后它会打印看似合理的调用图数据。

“超空间”警告是什么意思？是什么原因造成的？它会影响分析结果吗？我该如何解决？

Answer 1

Maynard Johnson 在 a message to a mailinglist 中解释了这个警告:

There have been cases reported where samples recorded by the oprofile kernel driver appear to be attributed to the wrong binary, in particular if the sample rate is very high or when doing callgraph profiling (since callgraph profiling, like a high sample rate, also results in very high overhead of the oprofile kernel driver and overflows of its internal sample buffers). I suspect that's what you're running into. Unfortunately, this is a very insidious bug, and no one has been able to find the root cause yet. The kernel driver does report overflow counts of its internal buffers, and the oprofiled log prints those out. As a convenience, starting with oprofile 0.9.5, opreport will also print a warning when it finds non-zero overflow counts and suggests lowering the sampling interval.

I suggest looking in your /var/lib/oprofile/samples/oprofiled.log and find the overflow statistics for the above profile run (log entries are timestamped). If you're only seeing a few or a very small percentage (say, less than 3%), you can probably just ignore the anomalies. In general, to avoid/limit this kind of thing, you should profile at the lowest sampling rate practical, especially when you're doing callgraph profiling. So what do I mean by "practical"? Well, as with any sample-based profiler, oprofile is statistical in nature. And the more data points you have, the more confidence you have in the data. So for 100% confidence, you should (theoretically) profile with a count value of '1'. Not too practical, though, since your machine may appear to lock up because most of the work being done is recording samples. For cycles event profiling, you can probably use a count value of several million or so (on today's processors) and still be pretty confident of the da ta. For other events, it really depends on their frequency of occurrence.