Linux 在比较物理硬件和基于kvm的虚拟机时遇到奇怪的rdtsc行为

我有以下问题。我在Linux机器上运行了几个压力测试

$ uname -a
Linux debian 3.14-2-686-pae #1 SMP Debian 3.14.15-2 (2014-08-09) i686 GNU/Linux

它是一款英特尔i5英特尔（R）核心（TM）i5-2400 CPU，支持3.10GHz、8G RAM和300G硬盘

这些测试不是I/O密集型测试，我主要通过以下方式计算双精度算术：

start = rdtsc();
do_arithmetic();
stop = rdtsc();
diff = stop - start;

我多次重复这些测试，在物理机器或基于KVM的VM上运行我的基准测试应用程序：

qemu-system-i386 disk.img -m 2000 -device virtio-net-pci,netdev=net1,mac=52:54:00:12:34:03 -netdev type=tap,id=net1,ifname=tap0,script=no,downscript=no -cpu host,+vmx -enable-kvm -nographichere

我收集许多试验的数据统计（即差异）。对于物理机器（未加载），我得到的数据处理延迟分布很可能是一个非常窄的对数正态分布

当我在虚拟机上重复实验（物理机和虚拟机未加载）时，对数正态分布仍然存在（形状稍宽一点），但是，我收集了几个点，完成时间比为物理机收集的绝对最小值要短得多（大约两倍）！！（请注意，物理机器上的完成时间分布非常窄，接近最小值）。还有一些点的完成时间比硬件机器上的平均完成时间长得多

我猜我的rdtsc基准测试方法对于VM环境不是很准确。您能否建议一种改进我的基准测试系统的方法，该系统可以在物理环境和基于kvm的虚拟环境之间提供可靠（可比较）的统计数据？至少在一些情况下，这不会告诉我虚拟机比硬件PC快2倍

提前感谢您对本主题的任何建议或意见

---

致以最诚挚的问候

也许你可以试试

clock\u gettime（clock\u THREAD\u CPUTIME\u ID，&ts）

，有关更多信息，请参阅

man clock\u gettime

这似乎根本不是rdtsc的问题。我通过带有用户空间调控器的acpi_cpufreq驱动程序以固定的有限频率使用我的i5 Intel内核。即使CPU速度固定在2.4 G（3.3G中的2.4 G），也有一些计算是以3.3 G的最大速度进行的。粗略地说，我在物理机器上也遇到了非常少的此类情况，每10000台中有1台。在kvm上，这种行为的频率更高，比如说大约百分之几。我会进一步调查这个问题

我不怀疑有任何改进，因为带有clock\u THREAD\u CPUTIME\u ID参数的clock\u gettime函数无论如何都是基于英特尔的TSC构建的。