小编tal*_*eDa的帖子

我正在尝试在 x86-64 处理器上分析执行时间的代码。我指的是这篇英特尔白皮书，并且还浏览了其他 SO 线程，讨论了在此处和此处使用 RDTSCP 与 CPUID+RDTSC 的主题。

在上面提到的白皮书中，使用 CPUID+RDTSC 的方法被称为不可靠，并且也使用统计数据进行了证明。

CPUID+RDTSC 不可靠的原因可能是什么？

此外，同一白皮书中的图 1（最小值行为图）和图 2（方差行为图）中的图具有“方波”模式。什么解释了这种模式？

我正在分析一个应用程序在运行 linux 的 x86-64 处理器上的执行时间。在开始对应用程序进行基准测试之前，我想确保禁用动态频率缩放和空闲状态。

检查频率缩放

$ cat /sys/devices/system/cpu/cpufreq/boost
0

这告诉我频率缩放（Intel 的 Turbo Boost 或 AMD 的 Turbo Core）被禁用。事实上，我们将其设置为恒定的 2GHz，这在下一个练习中很明显。

检查 CPU 空闲

$ cpupower --cpu 0-63 idle-info
CPUidle driver: none

CPUidle governor: menu
analyzing CPU 0:

CPU 0: No idle states

analyzing CPU 1:

CPU 1: No idle states

analyzing CPU 2:

CPU 2: No idle states
...

因此，空闲状态被禁用。现在我确定可以干扰基准测试的两个“功能”都被禁用，我继续使用 cpupower 监视应用程序。

但是，当我运行我的应用程序来监控 C 状态时，我发现超过 99% 的时间都花在了 C0 状态，这应该是这种情况。但是，我也看到了一种称为 Cx 状态的东西，其中内核花费了 0.01 - 0.02% 的时间。

$ cpupower monitor -c ./my_app …