Skylake 派生的 CPU 在负载/存储遇到瓶颈时会降低其核心时钟速度，而能源与性能设置有利于更省电。令人惊讶的是，您可以构建人为的情况，即使存储全部命中 L1d 缓存或从未初始化的内存加载（仍然 CoW 映射到相同的零页），也会发生这种降频。
Skylake 引入了对 CPU 频率的完全硬件控制（硬件 P-state = HWP）。 https://unix.stackexchange.com/questions/439340/what-are-the-implications-of-setting-the-cpu-governor-to-performance 频率决策可以考虑内部性能监控，它可以注意到诸如花费大多数周期停滞或停滞的事情。我不知道 Skylake 到底使用了什么启发式方法。
你可以通过循环一个大数组来重现这个1，而不需要进行任何系统调用。如果它很大（或者您在人工测试中跨越缓存行），perf stat ./a.out 将显示平均时钟速度低于正常的 CPU 绑定循环。
理论上，如果内存完全跟不上 CPU，降低核心时钟速度（并保持内存控制器不变）应该不会对性能造成太大影响。在实践中，降低时钟速度也会降低非核心时钟速度（环形总线 + L3 缓存），从而在一定程度上恶化内存延迟和带宽。
缓存未命中的部分延迟是从 CPU 内核获取请求到内存控制器，并且单核带宽受到最大并发（一个内核可以跟踪的未完成请求）/延迟的限制。 Why is Skylake so much better than Broadwell-E for single-threaded memory throughput?
例如我的 i7-6700k 在运行微基准测试时从 3.9GHz 下降到 2.7GHz，在默认启动设置下只有 DRAM 瓶颈。 （此外，它仅上升到 3.9GHz，而不是 4.0 全核或 4.2GHz，如 BIOS 中配置的那样，1 或 2 个内核处于活动状态，启动时默认 balance_power EPP 设置或 balance_performance。）
这个默认值似乎不太好，对于“客户端”芯片来说太保守了，因为单个内核几乎可以使 DRAM 带宽饱和，但只能以全时钟速度运行。或者在节能方面过于激进，如果你从另一个 POV 来看，尤其是对于像我的桌面这样具有高 TDP (95W) 的芯片，即使在运行 x265 视频编码等耗电的东西时也可以无限期地维持全时钟速度。 AVX2。
使用像 i5-8250U 这样的 ULV 15W 芯片可能更有意义，以便在 CPU 做更有趣的事情时留出更多的热量/功率余量。
这由他们的能源/性能偏好 (EPP) 设置管理。在默认的balance_power 设置下，这种情况相当强烈。 performance 完全不会发生这种情况，一些快速基准测试表明 balance_performance 也避免了这种省电减速。我在桌面上使用balance_performance。
Ice Lake 之前的“客户端”（非至强）芯片将所有内核锁定在一起，因此它们以相同的时钟速度运行（如果其中一个运行不受内存限制的东西，它们都会运行得更高，例如 @987654332 @ 环形）。但是每个逻辑核心仍然有一个 EPP 设置。我一直只是更改所有内核的设置以保持它们相同：
在 Linux 上，读取设置：
$ grep . /sys/devices/system/cpu/cpufreq/policy[0-9]*/energy_performance_preference
/sys/devices/system/cpu/cpufreq/policy0/energy_performance_preference:balance_performance
/sys/devices/system/cpu/cpufreq/policy1/energy_performance_preference:balance_performance
...
/sys/devices/system/cpu/cpufreq/policy7/energy_performance_preference:balance_performance
编写设置：
sudo sh -c 'for i in /sys/devices/system/cpu/cpufreq/policy[0-9]*/energy_performance_preference;
do echo balance_performance > "$i"; done'
另见
脚注1：实验示例：
每个高速缓存行存储 1 个 dword，通过连续的高速缓存行直到缓冲区结束，然后将指针回绕到开头。对固定数量的存储重复此操作，而不管缓冲区大小。
;; t=testloop; nasm -felf64 "$t.asm" && ld "$t.o" -o "$t" && taskset -c 3 perf stat -d -etask-clock,context-switches,cpu-migrations,page-faults,cycles,instructions,uops_issued.any,uops_executed.thread ./"$t"
;; nasm -felf64 testloop.asm
;; ld -o testloop testloop.o
;; taskset -c 3 perf stat -etask-clock,context-switches,cpu-migrations,page-faults,cycles,instructions,uops_issued.any,uops_executed.thread -r1 ./testloop
; or idq.mite_uops
default rel
%ifdef __YASM_VER__
; CPU intelnop
; CPU Conroe AMD
CPU Skylake AMD
%else
%use smartalign
alignmode p6, 64
%endif
global _start
_start:
lea rdi, [buf]
lea rsi, [endbuf]
; mov rsi, qword endbuf ; large buffer. NASM / YASM can't actually handle a huge BSS and hit a failed assert (NASM) or make a binary that doesn't reserve enough BSS space.
mov ebp, 1000000000
align 64
.loop:
%if 0
mov eax, [rdi] ; LOAD
mov eax, [rdi+64]
%else
mov [rdi], eax ; STORE
mov [rdi+64], eax
%endif
add rdi, 128
cmp rdi, rsi
jae .wrap_ptr ; normally falls through, total loop = 4 fused-domain uops
.back:
dec ebp
jnz .loop
.end:
xor edi,edi
mov eax,231 ; __NR_exit_group from /usr/include/asm/unistd_64.h
syscall ; sys_exit_group(0)
.wrap_ptr:
lea rdi, [buf]
jmp .back
section .bss
align 4096
;buf: resb 2048*1024*1024 - 1024*1024 ; just under 2GiB so RIP-rel still works
buf: resb 1024*1024 / 64 ; 16kiB = half of L1d
endbuf:
resb 4096 ; spare space to allow overshoot
测试系统：Arch GNU/Linux，内核 5.7.6-arch1-1。 （以及来自 GNU Binutils 2.34.0 的 NASM 2.14.02、ld）。
- CPU：i7-6700k Skylake
- 主板：Asus Z170 Pro Gaming，在 BIOS 中配置为 1 或 2 核睿频 = 4.2GHz，3 或 4 核 = 4.0GHz。但是启动时的默认 EPP 设置是
balance_power，它只能达到 3.9GHz。我的启动脚本更改为 balance_pwerformance，但仍只能达到 3.9GHz，因此风扇保持安静，但不那么保守。
- DRAM：DDR4-2666（与没有缓存未命中的小测试无关）。
超线程已启用，但系统处于空闲状态，内核不会在另一个逻辑内核（我将其固定到的同级内核）上调度任何内容，因此它自己拥有一个物理内核。
然而，这意味着 perf 不愿意为一个线程使用更多可编程的 perf 计数器，因此perf stat -d 来监控 L1d 负载和替换，而 L3 命中/未命中意味着对 cycles 等的测量精度较低。它可以忽略不计，例如 424k L1-dcache-loads（可能在内核页面错误处理程序、中断处理程序和其他开销中，因为循环没有负载）。 L1-dcache-load-misses 实际上是 L1D.REPLACEMENT 甚至更低，比如 48k
我使用了一些性能事件，包括exe_activity.bound_on_stores -[存储缓冲区已满且没有未完成负载的循环]。 （有关说明，请参阅perf list，和/或英特尔手册了解更多信息）。
EPP：balance_power：从 3.9GHz 降频 2.7GHz
EPP 设置：balance_power 和 sudo sh -c 'for i in /sys/devices/system/cpu/cpufreq/policy[0-9]*/energy_performance_preference;do echo balance_power > "$i";done'
根据代码正在执行的操作进行节流；另一个核心上的暂停循环保持时钟高，这将在此代码上运行得更快。或者在循环中使用不同的指令。
# sudo ... balance_power
$ taskset -c 3 perf stat -etask-clock:u,task-clock,context-switches,cpu-migrations,page-faults,cycles,branches,instructions,uops_issued.any,uops_executed.thread,exe_activity.bound_on_stores -r1 ./"$t"
Performance counter stats for './testloop':
779.56 msec task-clock:u # 1.000 CPUs utilized
779.56 msec task-clock # 1.000 CPUs utilized
3 context-switches # 0.004 K/sec
0 cpu-migrations # 0.000 K/sec
6 page-faults # 0.008 K/sec
2,104,778,670 cycles # 2.700 GHz
2,008,110,142 branches # 2575.962 M/sec
7,017,137,958 instructions # 3.33 insn per cycle
5,217,161,206 uops_issued.any # 6692.465 M/sec
7,191,265,987 uops_executed.thread # 9224.805 M/sec
613,076,394 exe_activity.bound_on_stores # 786.442 M/sec
0.779907034 seconds time elapsed
0.779451000 seconds user
0.000000000 seconds sys
碰巧恰好是 2.7GHz。通常会有一些噪音或启动开销，而且会低一些。请注意，5217951928 个前端 uops / 2106180524 个周期 = 每个周期发出的约 2.48 个平均 uops，流水线宽度为 4，因此这不是低吞吐量代码。由于宏融合比较/分支，指令计数更高。 （我本可以展开更多，所以更多的指令是存储，更少的添加和分支，但我没有。）
（我重新运行了几次perf stat 命令，因此 CPU 不仅仅是在定时间隔开始时从低功耗睡眠中唤醒。间隔中仍然存在页面错误，但有 6 个页面错误在 3/4 秒的基准测试中可以忽略不计。）
balance_performance：全 3.9GHz，此 EPP 的最高速度
不会根据代码正在执行的操作进行限制。
# sudo ... balance_performance
$ taskset -c 3 perf stat -etask-clock:u,task-clock,context-switches,cpu-migrations,page-faults,cycles,branches,instructions,uops_issued.any,uops_executed.thread,exe_activity.bound_on_stores -r1 ./"$t"
Performance counter stats for './testloop':
539.83 msec task-clock:u # 0.999 CPUs utilized
539.83 msec task-clock # 0.999 CPUs utilized
3 context-switches # 0.006 K/sec
0 cpu-migrations # 0.000 K/sec
6 page-faults # 0.011 K/sec
2,105,328,671 cycles # 3.900 GHz
2,008,030,096 branches # 3719.713 M/sec
7,016,729,050 instructions # 3.33 insn per cycle
5,217,686,004 uops_issued.any # 9665.340 M/sec
7,192,389,444 uops_executed.thread # 13323.318 M/sec
626,115,041 exe_activity.bound_on_stores # 1159.827 M/sec
0.540108507 seconds time elapsed
0.539877000 seconds user
0.000000000 seconds sys
在时钟对时钟的基础上大致相同，尽管存储缓冲区已满的总周期略多。 （这是在核心和 L1d 缓存之间，而不是在核心之间，所以我们希望循环本身大致相同。使用 -r10 重复 10 次，这个数字在运行中是稳定的 +- 0.01%。）
performance: 4.2GHz，完全加速到最高配置频率
不会根据代码正在执行的操作进行限制。
# sudo ... performance
taskset -c 3 perf stat -etask-clock,context-switches,cpu-migrations,page-faults,cycles,instructions,uops_issued.any,uops_executed.thread -r1 ./testloop
Performance counter stats for './testloop':
500.95 msec task-clock:u # 1.000 CPUs utilized
500.95 msec task-clock # 1.000 CPUs utilized
0 context-switches # 0.000 K/sec
0 cpu-migrations # 0.000 K/sec
7 page-faults # 0.014 K/sec
2,098,112,999 cycles # 4.188 GHz
2,007,994,492 branches # 4008.380 M/sec
7,016,551,461 instructions # 3.34 insn per cycle
5,217,839,192 uops_issued.any # 10415.906 M/sec
7,192,116,174 uops_executed.thread # 14356.978 M/sec
624,662,664 exe_activity.bound_on_stores # 1246.958 M/sec
0.501151045 seconds time elapsed
0.501042000 seconds user
0.000000000 seconds sys
整体性能与时钟速度呈线性关系，因此与balance_power 相比，速度提升了约 1.5 倍。 （balance_performance 为 1.44，具有相同的 3.9GHz 全时钟速度。）
如果缓冲区大到足以导致 L1d 或 L2 缓存未命中，核心时钟周期仍然存在差异。