performance - 英特尔丢失周期？rdtsc 和 CPU_CLK_UNHALTED.REF_TSC 之间的不一致

Question

在最近的 CPU 上（至少在过去十年左右），除了各种可配置的性能计数器外，英特尔还提供了三个固定功能的硬件性能计数器。三个固定计数器是：

INST_RETIRED.ANY
CPU_CLK_UNHALTED.THREAD
CPU_CLK_UNHALTED.REF_TSC

第一个计算退役指令，第二个计算实际周期数，最后一个是我们感兴趣的。英特尔软件开发人员手册第 3 卷的描述是：

当内核未处于停止状态且未处于 TM 停止时钟状态时，此事件以 TSC 速率计算参考周期数。内核在运行 HLT 指令或 MWAIT 指令时进入暂停状态。此事件不受核心频率变化（例如，P 状态）的影响，但以与时间戳计数器相同的频率计数。当内核未处于停止状态且未处于 TM 停止时钟状态时，此事件可以近似于经过的时间。

因此，对于受 CPU 限制的循环，我希望这个值与从读取的自由运行 TSC 值相同rdstc，因为它们应该只针对暂停的周期指令或“TM 停止时钟状态”是什么而发散。

我使用以下循环测试它（整个独立演示可在 github 上找到）：

for (int i = 0; i < 100; i++) {
    PFC_CNT cnt[7] = {};

    int64_t start = nanos();
    PFCSTART(cnt);
    int64_t tsc =__rdtsc();
    busy_loop(CALIBRATION_LOOPS);
    PFCEND(cnt);
    int64_t tsc_delta   = __rdtsc() - tsc;
    int64_t nanos_delta = nanos() - start;

    printf(CPU_W "d" REF_W ".2f" TSC_W ".2f" MHZ_W ".2f" RAT_W ".6f\n",
            sched_getcpu(),
            1000.0 * cnt[PFC_FIXEDCNT_CPU_CLK_REF_TSC] / nanos_delta,
            1000.0 * tsc_delta / nanos_delta,
            1000.0 * CALIBRATION_LOOPS / nanos_delta,
            1.0 * cnt[PFC_FIXEDCNT_CPU_CLK_REF_TSC]/tsc_delta);
}

定时区域中唯一重要的是busy_loop(CALIBRATION_LOOPS);它只是一个易失性存储的紧密循环，它由最近的硬件上的每次迭代编译gcc并clang执行一个周期：

void busy_loop(uint64_t iters) {
    volatile int sink;
    do {
        sink = 0;
    } while (--iters > 0);
    (void)sink;
}

PFCSTARTandPFCEND命令使用libpfcCPU_CLK_UNHALTED.REF_TSC读取计数器。这是通过指令读取 TSC 的内在函数。最后，我们测量实时时间，简单来说就是：__rdtsc()rdtscnanos()

int64_t nanos() {
    auto t = std::chrono::high_resolution_clock::now();
    return std::chrono::time_point_cast<std::chrono::nanoseconds>(t).time_since_epoch().count();
}

是的，我没有发出 a cpuid，而且事情并没有以精确的方式交错，但是校准循环是一整秒，所以这种纳秒级的问题只会被稀释到或多或少没有。

启用 TurboBoost 后，以下是在 i7-6700HQ Skylake CPU 上典型运行的前几个结果：

CPU# REF_TSC   rdtsc Eff Mhz     Ratio
   0 2392.05 2591.76 2981.30  0.922946
   0 2381.74 2591.79 3032.86  0.918955
   0 2399.12 2591.79 3032.50  0.925660
   0 2385.04 2591.79 3010.58  0.920230
   0 2378.39 2591.79 3010.21  0.917663
   0 2355.84 2591.77 2928.96  0.908970
   0 2364.99 2591.79 2942.32  0.912492
   0 2339.64 2591.77 2935.36  0.902720
   0 2366.43 2591.79 3022.08  0.913049
   0 2401.93 2591.79 3023.52  0.926747
   0 2452.87 2591.78 3070.91  0.946400
   0 2350.06 2591.79 2961.93  0.906733
   0 2340.44 2591.79 2897.58  0.903020
   0 2403.22 2591.79 2944.77  0.927246
   0 2394.10 2591.79 3059.58  0.923723
   0 2359.69 2591.78 2957.79  0.910449
   0 2353.33 2591.79 2916.39  0.907992
   0 2339.58 2591.79 2951.62  0.902690
   0 2395.82 2591.79 3017.59  0.924389
   0 2353.47 2591.79 2937.82  0.908047

这里，REF_TSC是如上所述的固定 TSC 性能计数器，rdtsc是rdtsc指令的结果。Eff Mhz是在该时间间隔内有效计算的真实 CPU 频率，主要是出于好奇和快速确认有多少 turbo 正在启动。Ratio是REF_TSC和rdtsc列的比率。我希望这非常接近 1，但实际上我们看到它在 0.90 到 0.92 之间徘徊，并且有很大的差异（我在其他运行中看到它低至 0.8）。

从图形上看，它看起来像这样²：

该rdstc调用返回几乎准确的结果¹，而 PMU TSC 计数器无处不在，有时几乎低至 2300 MHz。

但是，如果我关闭 turbo，结果会更加一致：

CPU# REF_TSC   rdtsc Eff Mhz     Ratio
   0 2592.26 2592.25 2588.30  1.000000
   0 2592.26 2592.26 2591.11  1.000000
   0 2592.26 2592.26 2590.40  1.000000
   0 2592.25 2592.25 2590.43  1.000000
   0 2592.26 2592.26 2590.75  1.000000
   0 2592.26 2592.26 2590.05  1.000000
   0 2592.25 2592.25 2590.04  1.000000
   0 2592.24 2592.24 2590.86  1.000000
   0 2592.25 2592.25 2590.35  1.000000
   0 2592.25 2592.25 2591.32  1.000000
   0 2592.25 2592.25 2590.63  1.000000
   0 2592.25 2592.25 2590.87  1.000000
   0 2592.25 2592.25 2590.77  1.000000
   0 2592.25 2592.25 2590.64  1.000000
   0 2592.24 2592.24 2590.30  1.000000
   0 2592.23 2592.23 2589.64  1.000000
   0 2592.23 2592.23 2590.83  1.000000
   0 2592.23 2592.23 2590.49  1.000000
   0 2592.23 2592.23 2590.78  1.000000
   0 2592.23 2592.23 2590.84  1.000000
   0 2592.22 2592.22 2588.80  1.000000

基本上，该比率是 1.000000 到6 位小数。

以图形方式（Y 轴刻度强制与上图相同）：

现在代码只是在运行一个热循环，应该没有hlt或mwait指令，当然没有任何暗示超过 10% 的变化。我不能确定什么是“TM 停止时钟周期”，但我敢打赌它们是“热管理停止时钟周期”，这是一种在达到最高温度时临时限制 CPU 的技巧。然而，我查看了集成热敏电阻的读数，我从来没有看到 CPU 突破 60C，远低于 90C-100C（我认为）。

知道这可能是什么吗？是否存在隐含的“停止周期”来在不同的涡轮频率之间转换？这肯定会发生，因为盒子不是安静的，所以当其他内核开始和停止在后台工作时，涡轮频率会上下跳跃（最大涡轮频率直接取决于活动内核的数量：在我的盒子上是 3.5， 3.3、3.2、3.1 GHz，分别用于 1、2、3 或 4 个活动核心）。

¹事实上，有一段时间我确实得到了精确到小数点后两位的结果：2591.97 MHz- 一次又一次的迭代。然后发生了一些变化，我不确定是什么，rdstc结果有大约 0.1% 的小变化。一种可能性是逐步调整时钟，由 Linux 计时子系统进行，以使本地晶体派生时间与ntpd确定的时间一致。也许，它只是一个晶体漂移——上面的最后一张图显示了每秒测量周期的稳定增加rdtsc。

²这些图表与文本中显示的值不对应相同的运行，因为我不会在每次更改文本输出格式时更新图表。然而，每次运行的定性行为基本相同。

score 28 · Accepted Answer

TL;博士

RDTSC您在和之间观察到的差异REFTSC是由 TurboBoost P 状态转换引起的。在这些转换过程中，包括固定功能性能计数器在内的大部分内核REF_TSC都会暂停大约 20000-21000 个周期（8.5us），但会rdtsc继续以不变的频率运行。rdtsc可能在一个隔离的电源和时钟域中，因为它非常重要并且因为它记录了类似挂钟的行为。

`RDTSC-REFTSC`差异_

这种差异表现为过度计算的RDTSC趋势REFTSC。程序运行的时间越长，差异RDTSC-REFTSC往往越积极。在很长的一段时间内，它可以高达 1%-2% 甚至更高。

当然，自己已经观察到，禁用TurboBoost时，过度计数会消失，使用时可以这样做intel_pstate：

echo 1 > /sys/devices/system/cpu/intel_pstate/no_turbo

但这并不能肯定地告诉我们 TurboBoost 对这种差异有过错。可能是 TurboBoost 启用的更高 P 状态会耗尽可用的净空，从而导致热节流和停止。

可能的节流？

TurboBoost 是一种动态频率和电压缩放解决方案，可适时利用工作包络（热或电）中的裕量。在可能的情况下，TurboBoost 会将处理器的核心频率和电压按比例提高到超出其标称值，从而以更高的功耗为代价提高性能。

更高的功耗当然会增加核心温度和功耗。最终，将达到某种限制，TurboBoost 将不得不降低性能。

TM1 热节流？

我首先调查了热监控器 1 (TM1) 或 2 (TM2) 的热控制电路 (TCC) 是否会导致热节流。TM1 通过插入 TM 停止时钟周期来降低功耗，这些是记录的导致REFTSC. 另一方面，TM2 不对时钟进行门控；它只缩放频率。

我进行了修改libpfc()以使我能够阅读选择的 MSR，特别是IA32_PACKAGE_THERM_STATUS和IA32_THERM_STATUSMSR。两者都包含用于各种热条件的只读状态和读写、硬件粘性日志标志：

（IA32_PACKAGE_THERM_STATUS注册表基本相同）

虽然有时会设置其中一些位（尤其是在阻塞笔记本电脑通风口时！），但它们似乎与RDTSC过度计数无关，无论热状态如何，这种情况都会可靠地发生。

硬件工作循环？C州居留权？

在 SDM 的其他地方挖掘类似停止时钟的硬件时，我偶然发现了 HDC（硬件占空比），这是一种操作系统可以手动请求 CPU 仅在固定比例的时间内运行的机制；HDC 硬件通过在每 16 个时钟周期运行处理器 1-15 个时钟周期并在该周期的剩余 15-1 个时钟周期强制空闲它来实现这一点。

HDC 提供了非常有用的寄存器，尤其是 MSR：

IA32_THREAD_STALL：计算由于此逻辑处理器上的强制空闲而停止的周期数。
MSR_CORE_HDC_RESIDENCY：与上述相同，但对于物理处理器，当该内核的一个或多个逻辑处理器强制空闲时计数周期。
MSR_PKG_HDC_SHALLOW_RESIDENCY：计算程序包处于 C2 状态并且至少一个逻辑处理器处于强制空闲状态的周期。
MSR_PKG_HDC_DEEP_RESIDENCY：计算程序包处于更深（精确可配置）C 状态并且至少一个逻辑处理器处于强制空闲状态的周期。

有关详细信息，请参阅英特尔 SDM 第 3 卷第 14 章第14.5.1 节硬件占空比编程接口。

但是我的 i7-4700MQ 2.4 GHz CPU 不支持 HDC，所以这就是 HDC。

其他节流来源？

在英特尔 SDM 中挖掘更多内容，我发现了一个非常非常多汁的 MSR MSR_CORE_PERF_LIMIT_REASONS：. 该寄存器报告了大量非常有用的状态和粘性日志位：

690H MSR_CORE_PERF_LIMIT_REASONS - 封装 - 处理器内核中的频率削波指示器

位0：PROCHOT 状态

位1：热状态

位4：显卡驱动状态。设置后，由于处理器图形驱动程序覆盖，频率会降低到操作系统请求以下。

位5：基于自主利用的频率控制状态。设置后，频率会降低到操作系统请求以下，因为处理器检测到利用率很低。

位6：电压调节器热警报状态。设置后，由于电压调节器的热警报，频率会降低到操作系统请求以下。

位8：电气设计点状态。设置后，由于电气设计点限制（例如最大电流消耗），频率会降低到操作系统要求以下。

位9：核心功率限制状态。设置后，由于域级功率限制，频率会降低到操作系统请求以下。

位10：封装级功率限制 PL1 状态。设置后，由于封装级功率限制 PL1，频率会降低到操作系统请求以下。

位11：封装级功率限制 PL2 状态。设置后，由于封装级功率限制 PL2，频率会降低到操作系统请求以下。

位12：最大涡轮限制状态。设置后，由于多核 turbo 限制，频率会降低到操作系统请求以下。

位13：Turbo 转换衰减状态。设置后，由于 Turbo 转换衰减，频率会降低到操作系统请求以下。这可以防止由于频繁的操作比变化而导致性能下降。

位16：PROCHOT 日志

位17：热日志

位20：图形驱动程序日志

位21：基于自主利用的频率控制日志

位22：电压调节器热警报日志

位24：电气设计点日志

位25：核心功率限制日志

位26：封装级功率限制 PL1 日志

位27：封装级功率限制 PL2 日志

位28：最大 Turbo 限制日志

位29：Turbo 转换衰减日志

pfc.ko现在支持此 MSR，并且演示打印这些日志位中的哪些是活动的。驱动程序在pfc.ko每次读取时清除粘滞位。

我在打印位时重新运行了您的实验，并且我的 CPU 在非常重的负载（所有 4 个内核/8 个线程都处于活动状态）下报告了几个限制因素，包括电气设计点和核心功率限制。由于我不知道的原因，始终在我的 CPU 上设置Package-Level PL2 和 Max Turbo Limit位。我也偶尔看到Turbo Transition Attenuation。

虽然这些位中没有一个与RDTSC-REFTSC差异的存在完全相关，但最后一位让我深思。Turbo Transition Attenuation的存在意味着切换 P 状态具有足够大的成本，因此必须通过某种滞后机制对其进行速率限制。当我找不到对这些转换进行计数的 MSR 时，我决定做下一件最好的事情 - 我将使用过度计数的幅度来描述 TurboBoost 转换的性能影响。RDTSC-REFTSC

实验

实验设置如下。在我的 i7-4700MQ CPU、标称速度 2.4GHz 和最大 Turbo Speed 3.4GHz 上，我将离线除 0（引导处理器）和 3（方便的受害者核心，不编号为 0 且不是 0 的逻辑兄弟）之外的所有核心。然后我们会要求intel_pstate司机给我们一个不低于98%不高于100%的包裹性能；这限制了处理器在第二高和最高 P 状态（3.3 GHz 和 3.4 GHz）之间振荡。我这样做如下：

echo   0 > /sys/devices/system/cpu/cpu1/online
echo   0 > /sys/devices/system/cpu/cpu2/online
echo   0 > /sys/devices/system/cpu/cpu4/online
echo   0 > /sys/devices/system/cpu/cpu5/online
echo   0 > /sys/devices/system/cpu/cpu6/online
echo   0 > /sys/devices/system/cpu/cpu7/online
echo  98 > /sys/devices/system/cpu/intel_pstate/min_perf_pct
echo 100 > /sys/devices/system/cpu/intel_pstate/max_perf_pct

我在以下位置运行了10000 个样本的演示应用程序

1000,     1500,     2500,     4000,     6300,
10000,    15000,    25000,    40000,    63000,
100000,   150000,   250000,   400000,   630000,
1000000,  1500000,  2500000,  4000000,  6300000,
10000000, 15000000, 25000000, 40000000, 63000000

以标称 CPU 频率执行的每次纳秒add_calibration()（将上面的数字乘以 2.4 以获得的实际参数add_calibration()）。

结果

这会产生如下所示的日志（250000 纳秒的情况）：

CPU 0, measured CLK_REF_TSC MHz        :          2392.56
CPU 0, measured rdtsc MHz              :          2392.46
CPU 0, measured add   MHz              :          3286.30
CPU 0, measured XREF_CLK  time (s)     :       0.00018200
CPU 0, measured delta     time (s)     :       0.00018258
CPU 0, measured tsc_delta time (s)     :       0.00018200
CPU 0, ratio ref_tsc :ref_xclk         :      24.00131868
CPU 0, ratio ref_core:ref_xclk         :      33.00071429
CPU 0, ratio rdtsc   :ref_xclk         :      24.00032967
CPU 0, core CLK cycles in OS           :                0
CPU 0, User-OS transitions             :                0
CPU 0, rdtsc-reftsc overcount          :              -18
CPU 0, MSR_IA32_PACKAGE_THERM_STATUS   : 000000008819080a
CPU 0, MSR_IA32_PACKAGE_THERM_INTERRUPT: 0000000000000003
CPU 0, MSR_CORE_PERF_LIMIT_REASONS     : 0000000018001000
        PROCHOT
        Thermal
        Graphics Driver
        Autonomous Utilization-Based Frequency Control
        Voltage Regulator Thermal Alert
        Electrical Design Point (e.g. Current)
        Core Power Limiting
        Package-Level PL1 Power Limiting
      * Package-Level PL2 Power Limiting
      * Max Turbo Limit (Multi-Core Turbo)
        Turbo Transition Attenuation
CPU 0, measured CLK_REF_TSC MHz        :          2392.63
CPU 0, measured rdtsc MHz              :          2392.62
CPU 0, measured add   MHz              :          3288.03
CPU 0, measured XREF_CLK  time (s)     :       0.00018192
CPU 0, measured delta     time (s)     :       0.00018248
CPU 0, measured tsc_delta time (s)     :       0.00018192
CPU 0, ratio ref_tsc :ref_xclk         :      24.00000000
CPU 0, ratio ref_core:ref_xclk         :      32.99983509
CPU 0, ratio rdtsc   :ref_xclk         :      23.99989006
CPU 0, core CLK cycles in OS           :                0
CPU 0, User-OS transitions             :                0
CPU 0, rdtsc-reftsc overcount          :               -2
CPU 0, MSR_IA32_PACKAGE_THERM_STATUS   : 000000008819080a
CPU 0, MSR_IA32_PACKAGE_THERM_INTERRUPT: 0000000000000003
CPU 0, MSR_CORE_PERF_LIMIT_REASONS     : 0000000018001000
        PROCHOT
        Thermal
        Graphics Driver
        Autonomous Utilization-Based Frequency Control
        Voltage Regulator Thermal Alert
        Electrical Design Point (e.g. Current)
        Core Power Limiting
        Package-Level PL1 Power Limiting
      * Package-Level PL2 Power Limiting
      * Max Turbo Limit (Multi-Core Turbo)
        Turbo Transition Attenuation
CPU 0, measured CLK_REF_TSC MHz        :          2284.69
CPU 0, measured rdtsc MHz              :          2392.63
CPU 0, measured add   MHz              :          3151.99
CPU 0, measured XREF_CLK  time (s)     :       0.00018121
CPU 0, measured delta     time (s)     :       0.00019036
CPU 0, measured tsc_delta time (s)     :       0.00018977
CPU 0, ratio ref_tsc :ref_xclk         :      24.00000000
CPU 0, ratio ref_core:ref_xclk         :      33.38540919
CPU 0, ratio rdtsc   :ref_xclk         :      25.13393301
CPU 0, core CLK cycles in OS           :                0
CPU 0, User-OS transitions             :                0
CPU 0, rdtsc-reftsc overcount          :            20548
CPU 0, MSR_IA32_PACKAGE_THERM_STATUS   : 000000008819080a
CPU 0, MSR_IA32_PACKAGE_THERM_INTERRUPT: 0000000000000003
CPU 0, MSR_CORE_PERF_LIMIT_REASONS     : 0000000018000000
        PROCHOT
        Thermal
        Graphics Driver
        Autonomous Utilization-Based Frequency Control
        Voltage Regulator Thermal Alert
        Electrical Design Point (e.g. Current)
        Core Power Limiting
        Package-Level PL1 Power Limiting
      * Package-Level PL2 Power Limiting
      * Max Turbo Limit (Multi-Core Turbo)
        Turbo Transition Attenuation
CPU 0, measured CLK_REF_TSC MHz        :          2392.46
CPU 0, measured rdtsc MHz              :          2392.45
CPU 0, measured add   MHz              :          3287.80
CPU 0, measured XREF_CLK  time (s)     :       0.00018192
CPU 0, measured delta     time (s)     :       0.00018249
CPU 0, measured tsc_delta time (s)     :       0.00018192
CPU 0, ratio ref_tsc :ref_xclk         :      24.00000000
CPU 0, ratio ref_core:ref_xclk         :      32.99978012
CPU 0, ratio rdtsc   :ref_xclk         :      23.99989006
CPU 0, core CLK cycles in OS           :                0
CPU 0, User-OS transitions             :                0
CPU 0, rdtsc-reftsc overcount          :               -2
CPU 0, MSR_IA32_PACKAGE_THERM_STATUS   : 000000008819080a
CPU 0, MSR_IA32_PACKAGE_THERM_INTERRUPT: 0000000000000003
CPU 0, MSR_CORE_PERF_LIMIT_REASONS     : 0000000018001000
        PROCHOT
        Thermal
        Graphics Driver
        Autonomous Utilization-Based Frequency Control
        Voltage Regulator Thermal Alert
        Electrical Design Point (e.g. Current)
        Core Power Limiting
        Package-Level PL1 Power Limiting
      * Package-Level PL2 Power Limiting
      * Max Turbo Limit (Multi-Core Turbo)
        Turbo Transition Attenuation

我对日志做了一些观察，但有一个很突出：

对于 nanos < ~250000，RDTSC 的过度计数可以忽略不计。对于 nanos > ~250000，可以可靠地观察到刚好超过 20000 个时钟周期的过度计数时钟周期量。但它们不是由于用户-操作系统转换。

这是一个视觉图：

饱和蓝点：0 标准差（接近平均值）

饱和红点：+3 标准差（高于平均值）

饱和绿点：-3 标准差（低于平均值）

在大约 250000 纳秒的持续递减之前、期间和之后存在显着差异。

纳米 < 250000

在阈值之前，CSV 日志如下所示：

24.00,33.00,24.00,-14,0,0
24.00,33.00,24.00,-20,0,0
24.00,33.00,24.00,-4,3639,1
24.00,33.00,24.00,-20,0,0
24.00,33.00,24.00,10,0,0
24.00,33.00,24.00,10,0,0
24.00,33.00,24.00,-14,0,0
24.00,33.00,24.00,-14,0,0
24.00,33.00,24.00,10,0,0
24.00,33.00,24.00,-44,0,0
24.00,33.00,24.00,10,0,0
24.00,33.00,24.00,-14,0,0
24.00,33.00,24.00,-20,0,0
24.00,33.00,24.00,10,0,0
24.00,33.00,24.00,10,0,0
24.00,33.00,24.00,10,0,0
24.00,33.00,24.00,10,0,0
24.00,33.00,24.00,-20,0,0
24.00,33.00,24.00,10,0,0
24.00,33.00,24.00,10,0,0
24.00,33.00,24.00,10,0,0
24.00,33.00,24.00,10,0,0
24.00,33.00,24.00,12,0,0
24.00,33.00,24.00,10,0,0
24.00,33.00,24.00,10,0,0
24.00,33.00,24.00,10,0,0
24.00,33.00,24.00,10,0,0
24.00,33.00,24.00,10,0,0
24.00,33.00,24.00,10,0,0
24.00,33.00,24.00,-20,0,0
24.00,33.00,24.00,32,3171,1
24.00,33.00,24.00,-20,0,0
24.00,33.00,24.00,10,0,0

表明 TurboBoost 比率完全稳定在 33 倍，与24 倍（100 MHz）的速率RDTSC同步计数，可忽略不计的过度计数，通常在内核中花费 0 个周期，因此 0 个转换到内核。内核中断服务大约需要 3000 个参考周期。REFTSCREF_XCLK

纳米 == 250000

在临界阈值处，日志包含 20000 个循环超计数的块，并且超计数与 33x 和 34x 之间的非整数估计乘数值非常相关：

24.00,33.00,24.00,-2,0,0
24.00,33.00,24.00,-2,0,0
24.00,33.00,24.00,2,0,0
24.00,33.00,24.00,22,0,0
24.00,33.00,24.00,-2,0,0
24.00,33.00,24.00,-2,0,0
24.00,33.00,24.00,-2,0,0
24.00,33.05,25.11,20396,0,0
24.00,33.38,25.12,20212,0,0
24.00,33.39,25.12,20308,0,0
24.00,33.42,25.12,20296,0,0
24.00,33.43,25.11,20158,0,0
24.00,33.43,25.11,20178,0,0
24.00,33.00,24.00,-4,0,0
24.00,33.00,24.00,20,3920,1
24.00,33.00,24.00,-2,0,0
24.00,33.00,24.00,-4,0,0
24.00,33.44,25.13,20396,0,0
24.00,33.46,25.11,20156,0,0
24.00,33.46,25.12,20268,0,0
24.00,33.41,25.12,20322,0,0
24.00,33.40,25.11,20216,0,0
24.00,33.46,25.12,20168,0,0
24.00,33.00,24.00,-2,0,0
24.00,33.00,24.00,-2,0,0
24.00,33.00,24.00,-2,0,0
24.00,33.00,24.00,22,0,0

纳米 > 250000

从 3.3 GHz 到 3.4 GHz 的 TurboBoost 现在可以可靠地发生。随着纳米的增加，日志中充满了大约 20000 周期量子的整数倍。最终有太多的 nano 以至于 Linux 调度程序中断成为永久固定装置，但是使用性能计数器很容易检测到抢占，其效果与 TurboBoost 停止完全不同。

24.00,33.75,24.45,20166,0,0
24.00,33.78,24.45,20302,0,0
24.00,33.78,24.45,20202,0,0
24.00,33.68,24.91,41082,0,0
24.00,33.31,24.90,40998,0,0
24.00,33.70,25.30,58986,3668,1
24.00,33.74,24.42,18798,0,0
24.00,33.74,24.45,20172,0,0
24.00,33.77,24.45,20156,0,0
24.00,33.78,24.45,20258,0,0
24.00,33.78,24.45,20240,0,0
24.00,33.77,24.42,18826,0,0
24.00,33.75,24.45,20372,0,0
24.00,33.76,24.42,18798,4081,1
24.00,33.74,24.41,18460,0,0
24.00,33.75,24.45,20234,0,0
24.00,33.77,24.45,20284,0,0
24.00,33.78,24.45,20150,0,0
24.00,33.78,24.45,20314,0,0
24.00,33.78,24.42,18766,0,0
24.00,33.71,25.36,61608,0,0
24.00,33.76,24.45,20336,0,0
24.00,33.78,24.45,20234,0,0
24.00,33.78,24.45,20210,0,0
24.00,33.78,24.45,20210,0,0
24.00,33.00,24.00,-10,0,0
24.00,33.00,24.00,4,0,0
24.00,33.00,24.00,18,0,0
24.00,33.00,24.00,2,4132,1
24.00,33.00,24.00,44,0,0

结论

TurboBoost 机械是造成RDTSC-REFTSC. 此差异可用于确定从 3.3 GHz 到 3.4 GHz 的 TurboBoost 状态转换大约需要 20500 个参考时钟周期（8.5us），并且在进入后不迟于大约 250000 ns（250us；600000 个参考时钟周期）触发add_reference()，当处理器决定工作负载足够强烈以至于值得进行频率-电压缩放时。

未来的工作

需要做更多的研究来确定转换成本如何随频率变化，以及选择电源状态的硬件是否可以调整。我特别感兴趣的是“Turbo Attenuation Units”，我在网络的远端看到了一些提示。也许 Turbo 硬件有一个可配置的时间窗口？目前，决定时间与转换时间的比率为 30:1 (600us:20us)。可以调吗？

performance - 英特尔丢失周期？rdtsc 和 CPU_CLK_UNHALTED.REF_TSC 之间的不一致

1 回答 1