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

Question

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

INST_RETIRED.ANY
CPU_CLK_UNHALTED.THREAD
CPU_CLK_UNHALTED.REF_TSC

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

This event counts the number of reference cycles at the TSC rate when the core is not in a halt state and not in a TM stop-clock state. The core enters the halt state when it is running the HLT instruction or the MWAIT instruction. This event is not affected by core frequency changes (e.g., P states) but counts at the same frequency as the time stamp counter. This event can approximate elapsed time while the core was not in a halt state and not in a TM stopclock state.

因此对于 CPU 绑定循环，我希望此值与从 rdstc 读取的自由运行ning TSC 值相同，因为它们应该只发散对于暂停循环指令或 "TM stopclock state" 是什么。

我用下面的循环（整个standalone demo is available on 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);，它只是一个易失性存储的紧密循环，as compiled由gcc和clang同时执行最近硬件上每次迭代的周期：

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

PFCSTART 和 PFCEND 命令使用 libpfc 读取 CPU_CLK_UNHALTED.REF_TSC 计数器。 __rdtsc() 是一个内在函数，它通过 rdtsc 指令读取 TSC。最后，我们用 nanos() 测量实时，它很简单：

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();
}

是的，我没有发布 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 频率，主要出于好奇而显示，并作为快速确认涡轮增压量的快速确认。Ratio 是 [= 的比率28=] 和 rdtsc 列。我希望它非常接近 1，但实际上我们看到它徘徊在 0.90 到 0.92 之间，有很大的差异（我在其他运行s 上看到它低至 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 stop-clock cycles"，但我敢打赌它们是 "thermal management stop-clock cycles"，一个用来暂时限制 CPU 的技巧当达到最高温度时。然而，我查看了集成的热敏电阻读数，但我从未看到 CPU 突破 60C，远低于终端管理启动的 90C-100C（我认为）。

知道这是什么吗？是否暗示 "halt cycles" 在不同的涡轮频率之间转换？这肯定会发生，因为盒子并不安静，所以当其他内核开始和停止处理背景内容时，turbo 频率上下跳跃（最大 turbo 频率直接取决于活动内核的数量：在我的盒子上它是 3.5， 3.3、3.2、3.1 GHz 分别适用于 1、2、3 或 4 个活动内核。

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

² 这些图表与文本中显示的值不对应相同的运行s 因为我不打算更新每个图表是时候更改文本输出格式了。但是，每个运行的定性行为基本相同。

Answer 1

TL;DR

您在 RDTSC 和 REFTSC 之间观察到的差异是由 TurboBoost P 状态 t运行引起的。在这些 t运行期间，大部分内核（包括固定功能性能计数器 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 将不得不降低性能 c运行k。

TM1 热节流？

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

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

(The IA32_PACKAGE_THERM_STATUS register is substantially the same)

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

硬件负载循环？ C 州居留权？

在 SDM 的其他地方挖掘类似停止时钟的硬件我偶然发现了 HDC（硬件占空比），OS 可以手动请求 CPU 仅运行一个机制固定比例的时间； HDC 硬件通过运行处理器每 16 个时钟周期执行 1-15 个时钟周期，并 force-idling 执行该周期剩余的 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。

其他节流源？

在 Intel SDM 中进一步挖掘，我发现了一个 非常非常 多汁的 MSR：MSR_CORE_PERF_LIMIT_REASONS。该寄存器报告了大量非常有用的 Status 和 sticky Log 位：

690H MSR_CORE_PERF_LIMIT_REASONS - Package - Indicator of Frequency Clipping in Processor Cores

Bit 0: PROCHOT Status

Bit 1: Thermal Status

Bit 4: Graphics Driver Status. When set, frequency is reduced below the operating system request due to Processor Graphics driver override.

Bit 5: Autonomous Utilization-Based Frequency Control Status. When set, frequency is reduced below the operating system request because the processor has detected that utilization is low.

Bit 6: Voltage Regulator Thermal Alert Status. When set, frequency is reduced below the operating system request due to a thermal alert from the Voltage Regulator.

Bit 8: Electrical Design Point Status. When set, frequency is reduced below the operating system request due to electrical design point constraints (e.g. maximum electrical current consumption).

Bit 9: Core Power Limiting Status. When set, frequency is reduced below the operating system request due to domain-level power limiting.

Bit 10: Package-Level Power Limiting PL1 Status. When set, frequency is reduced below the operating system request due to package-level power limiting PL1.

Bit 11: Package-Level Power Limiting PL2 Status. When set, frequency is reduced below the operating system request due to package-level power limiting PL2.

Bit 12: Max Turbo Limit Status. When set, frequency is reduced below the operating system request due to multi-core turbo limits.

Bit 13: Turbo Transition Attenuation Status. When set, frequency is reduced below the operating system request due to Turbo transition attenuation. This prevents performance degradation due to frequent operating ratio changes.

Bit 16: PROCHOT Log

Bit 17: Thermal Log

Bit 20: Graphics Driver Log

Bit 21: Autonomous Utilization-Based Frequency Control Log

Bit 22: Voltage Regulator Thermal Alert Log

Bit 24: Electrical Design Point Log

Bit 25: Core Power Limiting Log

Bit 26: Package-Level Power Limiting PL1 Log

Bit 27: Package-Level Power Limiting PL2 Log

Bit 28: Max Turbo Limit Log

Bit 29: Turbo Transition Attenuation Log

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

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

虽然这些位中的 none 与 RDTSC-REFTSC 差异的存在完全相关，但最后一位让我深思。 Turbo T运行sition Attenuation 的 existence 意味着切换 P-State 具有足够大的成本，它必须是速率- 受限于某些滞后机制。当我找不到计算这些 t运行sitions 的 MSR 时，我决定做下一个最好的事情——我将使用 RDTSC-REFTSC overcount 的幅度来表征 TurboBoost t 的性能影响运行位置。

实验

实验设置如下。在我的 i7-4700MQ CPU、标称速度 2.4GHz 和最大 Turbo 速度 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

我运行 demo 申请 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

每 add_calibration() 以标称 CPU 频率执行的纳秒（将上面的数字乘以 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

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

对于 < ~250000 的纳秒，RDTSC 过度计数可以忽略不计。对于 nanos > ~250000，可以可靠地观察到超过 20000 个时钟周期的过度计数时钟周期 quanta。但由于 User-OS t运行sitions.

，它们 not

这是一个视觉图：

Saturated Blue Dots: 0 standard deviations (close to mean)

Saturated Red Dots: +3 standard deviations (above mean)

Saturated Green Dots: -3 standard deviations (below mean)

在大约 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 倍时完全稳定，RDTSC 与 REFTSC 同步计数，速率是 REF_XCLK (100 MHz) 的 24 倍，可以忽略不计的过度计数，通常为 0在内核中花费的周期，因此 0 t运行进入内核。内核中断需要大约 3000 个参考周期才能服务。

纳米 == 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 状态 t运行sition 需要大约 20500 个参考时钟周期（8.5us），并且不迟于大约 250000 ns（250us；600000 参考时钟）被触发周期）进入 add_reference() 后，当处理器确定工作负载足够大，值得进行频率-电压缩放时。

未来的工作

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

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

Lost Cycles on Intel? An inconsistency between rdtsc and CPU_CLK_UNHALTED.REF_TSC

performance

x86

x86-64

cpu-architecture

rdtsc

TL;DR

`RDTSC-REFTSC` 差异

可能节流？

TM1 热节流？

硬件负载循环？ C 州居留权？

其他节流源？

690H MSR_CORE_PERF_LIMIT_REASONS - Package - Indicator of Frequency Clipping in Processor Cores

实验

结果

纳米 < 250000

纳米 == 250000

纳米 > 250000

结论

未来的工作

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

Lost Cycles on Intel? An inconsistency between rdtsc and CPU_CLK_UNHALTED.REF_TSC

performance

x86

x86-64

cpu-architecture

rdtsc

TL;DR

RDTSC-REFTSC 差异

可能节流？

TM1 热节流？

硬件负载循环？ C 州居留权？

其他节流源？

690H MSR_CORE_PERF_LIMIT_REASONS - Package - Indicator of Frequency Clipping in Processor Cores

实验

结果

纳米 < 250000

纳米 == 250000

纳米 > 250000

结论

未来的工作

`RDTSC-REFTSC` 差异