經驗豐富的奇怪rdtsc行爲比較物理硬件和基於kvm的虛擬機

我有以下問題。我在Linux機器經驗豐富的奇怪rdtsc行爲比較物理硬件和基於kvm的虛擬機

$ 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的HDD。

這些測試不是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快兩倍。

在此先感謝您對此主題的任何建議或意見。

問候

來源

2014-09-10 Eryk

也許你可以試試clock_gettime(CLOCK_THREAD_CPUTIME_ID,&ts)，看到man clock_gettime更多信息

來源

2014-09-11 01:43:30 ioilala

我不懷疑有任何改進，因爲帶有CLOCK_THREAD_CPUTIME_ID參數的clock_gettime函數是建立在英特爾上的TSC上的。 – Eryk 2014-09-11 07:11:36

看來，這不是RDTSC的問題都沒有。我正通過acpi_cpufreq驅動程序與用戶空間管理器一起使用我的i5英特爾核心，其固定頻率有限。儘管CPU速度固定在2.4G（3.3G之外），但有一些計算以3.3G的最大速度執行。粗略地說，我在物理機器上也遇到了很少的這種情況〜 1/10,000。在kvm上，這種行爲的頻率更高，比如說幾個百分點。我會進一步調查這個問題。

來源

2014-09-12 11:53:13 Eryk

經驗豐富的奇怪rdtsc行爲比較物理硬件和基於kvm的虛擬機

回答

相關問題