performance - 在英特尔上丢了周期？ rdtsc和CPU_CLK_UNHALTED.REF_TSC之间不一致

在最近的CPU(至少最近十年左右)上，英特尔提供了三个固定功能的硬件性能计数器，以及各种可配置的性能计数器。三个固定计数器是:

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读取的自由运行的TSC值相同，因为它们仅应在停止的循环指令或“TM停止时钟状态”是不同的情况下才发散。

我使用以下循环(整个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);，它只是 Volatile 存储的紧密循环，通过gcc和clang的as compiled在最新的硬件上每次迭代执行一次:

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频率，主要出于好奇的考虑而显示，并可以快速确认启动了多少turbo。Ratio是REF_TSC和rdtsc列的比率。我希望它非常接近于1，但实际上我们看到它在0.90到0.92之间徘徊，并且有很大的差异(在其他运行中我发现它低至0.8)。

在图形上看起来像这样:

rdstc调用返回的结果几乎准确1，而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，远低于90°C-100C引起术语管理的地方(我认为)。

知道这可能是什么吗？是否存在在不同涡轮频率之间转换的隐式“停止周期”？确实会发生这种情况，因为机箱并不安静，所以turbo频率会随着其他内核在后台进程上的启动和停止工作而跳升或降落(最大turbo频率直接取决于 Activity 内核的数量:在我的盒子上是3.5， 1个，2个，3个或4个 Activity 内核分别为3.3、3.2、3.1 GHz)。

1实际上，有一段时间我确实将精确的结果精确到两位小数:2591.97 MHz-迭代之后的迭代。然后发生了一些变化，我不确定是什么，而且rdstc结果大约有0.1％的微小差异。一种可能是逐步时钟调整，这是由Linux计时子系统进行的，以使本地晶体导出的时间与ntpd确定的时间保持一致。也许，这仅仅是晶体漂移-上面的最后一张图显示了rdtsc的测量周期每秒稳定增加。

2这些图形与文本中显示的值所对应的运行时间不同，因为每次更改文本输出格式时我都不会更新图形。但是，每次运行的定性行为基本相同。

最佳答案

TL; DR

您在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_STATUS MSR。两者都包含针对各种热条件的只读状态和可读写的硬件粘性日志标志:

(The IA32_PACKAGE_THERM_STATUS register is substantially the same)

尽管有时会设置其中一些位(尤其是在阻塞笔记本电脑的通风口时!)，但它们似乎与RDTSC过度计数无关，而odt_code过度计数会可靠地发生，而与热状态无关。

硬件责任循环？州长居留权？

在SDM中挖掘类似停止时钟的硬件时，我碰巧遇到了HDC(硬件占空比)，通过这种机制，OS可以手动请求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节“硬件占空比编程”接口(interface)。

但是我的i7-4700MQ 2.4 GHz CPU不支持HDC，因此HDC就是这样。

节流的其他来源？

在Intel SDM中进一步挖掘一些内容，我发现了一个非常非常多汁的MSR:MSR_CORE_PERF_LIMIT_REASONS。该寄存器报告了大量非常有用的状态和粘性日志位:

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打印这些日志位中的哪个处于 Activity 状态。 pfc.ko驱动程序在每次读取时清除粘性位。

我在打印位时重新进行了实验，我的CPU在非常重的负载(所有4个内核/ 8个线程都处于 Activity 状态)下报告了一些限制因素，包括电气设计点和内核功率限制。出于我未知的原因，总是在我的CPU上设置Package-Level PL2和Max Turbo Limit位。我还偶尔看到Turbo过渡衰减。

虽然这些位都没有与RDTSC-REFTSC差异的存在完全相关，但最后一位给了我深思。 Turbo过渡衰减的仅存在意味着切换P状态具有相当大的成本，必须通过某种滞后机制来限制速率。当我找不到计算这些转换的MSR时，我决定做下一件最好的事情-我将使用RDTSC-REFTSC overcount的大小来表征TurboBoost转换对性能的影响。

实验

实验设置如下。在我的i7-4700MQ CPU(标称速度2.4GHz和最大Turbo Speed 3.4 GHz)上，我将使所有内核(除了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

在标称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

我对原木做了几项观察，但其中一个引人注目:

对于小于约250000的nanos，RDTSC的超计数可以忽略不计。对于> 250000的nano，可以可靠地观察到超过20000个时钟周期的超计数时钟周期量子。但是它们不是由于用户OS转换造成的。

这是一个视觉图:

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过渡到内核。内核中断需要大约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状态转换大约需要20500个引用时钟周期(8.5us)，并且在输入add_reference()后不迟于大约250000 ns(250us； 600000个引用时钟周期)触发，当处理器认为工作量足够紧张以至于不应该进行频率-电压缩放时。

future 的工作

需要做更多的研究来确定转换成本如何随频率变化，以及是否可以调整选择电源状态的硬件。我特别感兴趣的是“Turbo衰减单元”，我在网络的远处都看到了这些提示。也许Turbo硬件具有可配置的时间窗口？当前，决定花费的时间与过渡所花费的时间之比为30:1(600us:20us)。可以调整吗？

关于performance - 在英特尔上丢了周期？ rdtsc和CPU_CLK_UNHALTED.REF_TSC之间不一致，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/45472147/

performance - 在英特尔上丢了周期？ rdtsc和CPU_CLK_UNHALTED.REF_TSC之间不一致

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

上一篇：dll - 什么是 “.dll.a”文件？

下一篇：design-patterns - 跨微服务的数据一致性