Intel 上的不同 CPU 频率 [关闭]

问题描述 投票：0回答：1

我有一台规格为 Intel 的服务器：

Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                56
On-line CPU(s) list:   0-55
Thread(s) per core:    1
Core(s) per socket:    28
Socket(s):             2
NUMA node(s):          2
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 85
Model name:            Intel(R) Xeon(R) Gold 6258R CPU @ 2.70GHz
Stepping:              7
CPU MHz:               2700.000
BogoMIPS:              5400.00
Virtualization:        VT-x
L1d cache:             32K
L1i cache:             32K
L2 cache:              1024K
L3 cache:              39424K
NUMA node0 CPU(s):     0,2,4,6,8,10,12,14,16,18,20,22,24,26,28,30,32,34,36,38,40,42,44,46,48,50,52,54
NUMA node1 CPU(s):     1,3,5,7,9,11,13,15,17,19,21,23,25,27,29,31,33,35,37,39,41,43,45,47,49,51,53,55
Flags:                 fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb cat_l3 cdp_l3 invpcid_single intel_ppin ssbd mba ibrs ibpb stibp ibrs_enhanced tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm cqm mpx rdt_a avx512f avx512dq rdseed adx smap clflushopt clwb intel_pt avx512cd avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local dtherm ida arat pln pts pku ospke avx512_vnni md_clear flush_l1d arch_capabilities

系统是idle，我检查核心的当前频率，我观察到：

如您所见，其中一个内核的运行频率低于其余内核。实际上有几个内核以较低的频率 (1000 MHz) 运行，但在图像中您只能看到一个。这是什么原因，是预料之中的吗？频率较低的核心并不总是相同的，所以我不认为特定核心有问题。

x86 cpu cpu-architecture intel
1个回答
1
投票

CPU 频率随每个内核的负载而变化是正常的，读取当前 CPU 频率会产生负载。

可能是将内核任务调度到该内核以读取其 CPU 信息并格式化文本以进行读取系统调用的工作

/proc/cpuinfo
通常会导致频率从空闲（大概 1000 MHz）跳到其最大非在读取频率之前，涡轮速度为 2700 MHz。但有时这种情况会在 CPU 频率控制器对短暂的负载爆发做出反应之前快速发生。

硬件 P-state 管理在默认情况下确实反应非常快，这是 Skylake 和更新的 Intel CPU 的一个特性。

读取每个核心频率的低开销方法可能存在，例如分别为每个 CPU 读取

/sys/devices/system/cpu/cpufreq/policy*/scaling_cur_freq
。例如在我的 i7-6700k（Skylake“客户端”）上，超线程布局枚举了每个物理内核的一个逻辑内核，然后再次遍历逻辑内核：

$ cat /sys/devices/system/cpu/cpufreq/policy*/scaling_cur_freq 
800015  
800003
800039
800099   # the first time we do anything on each physical core, it was at 800 MHz
4000000  # logical core 4 is physical core 0 again.  It's ramped to 4GHz now.
4000000
799384
800123

$ grep . /sys/devices/system/cpu/cpufreq/policy*/scaling_cur_freq 
/sys/devices/system/cpu/cpufreq/policy0/scaling_cur_freq:807751
/sys/devices/system/cpu/cpufreq/policy1/scaling_cur_freq:4000000
/sys/devices/system/cpu/cpufreq/policy2/scaling_cur_freq:800003
/sys/devices/system/cpu/cpufreq/policy3/scaling_cur_freq:4000000
/sys/devices/system/cpu/cpufreq/policy4/scaling_cur_freq:4000000
/sys/devices/system/cpu/cpufreq/policy5/scaling_cur_freq:807804
/sys/devices/system/cpu/cpufreq/policy6/scaling_cur_freq:4000000
/sys/devices/system/cpu/cpufreq/policy7/scaling_cur_freq:800102

grep 有更多开销并获得更多高达 4GHz 的内核。

您可以通过调整能源性能偏好 (EPP) 来设置硬件 P 状态管理的积极程度。 

sudo sh -c 'for i in /sys/devices/system/cpu/cpufreq/policy[0-9]*/energy_performance_preference;do echo balance_performance > "$i";done'

其他可用设置（在 

energy_performance_available_preferences
中列出）是 
power
（最不激进）、
balance_power
、
balance_performance
和 
performance
（醒来时几乎立即跳转到最大涡轮增压，并减少降频以获得受内存限制的核心）。我发现 
balance_performance
对我的桌面来说是合理的，可以让风扇一直保持安静，但它不会做涡轮增压（从 4.0 到 4.2 GHz），除非我设置 
performance
.

要检查您当前的 EPP 设置，

grep . /sys/devices/system/cpu/cpufreq/policy[0-9]*/energy_performance_preference
是打印文件名和设置的便捷方式。

在服务器 CPU 上，每个内核实际上都可以独立更改频率，这与“客户端”CPU 不同，我认为任何/所有非睡眠内核都以相同的时钟速度运行，除了涡轮高于额定“标签”频率（你可以在 CPUID 型号名称中看到）。

另见

正如 Bandwidth 博士在评论中指出：

问题是无法从用户空间指令中获取“当前”频率。从每个内核获取频率需要进入内核，设置一系列处理器间中断以在目标内核上执行 RDMSR 指令，然后将信息返回给用户空间。跨入内核执行所需的 RDMSR 指令足以引起频率变化。提供一分钟的运行平均值可能更好？

这对于 

/proc/cpuinfo
接口来说尤其糟糕，它必须获得每个 CPU 的频率。
/sys/devices/system/cpu/cpufreq/policy<CORE_NUMBER>/scaling_cur_freq
API 理论上可以针对您正在阅读的核心 # 是该任务已经运行的核心的情况进行优化，这将避免 IPI。

使用

perf stat
来计算一个时间间隔内的
cycles
事件会给你平均频率；这是个好建议。但前提是您要测量每个进程的时间，所以时间 (
task-clock
) 只会在时钟未停止时滴答作响。如果您使用 
perf stat -a
来测量系统范围内的跨进程核心，时间会滴答作响，而时钟不会。所以你可以获得低于
scaling_min_freq
.

的频率 

lcpu
将显示实际的最小/最大频率

如果您只是想知道核心 可以 时钟在空闲时下降到什么频率，或者在最大涡轮增压时上升到什么频率，

lscpu
中的 
util-linux
是一个很好的工具。 （我认为 
lscpu
有多种实现。）请注意 CPU max MHz 和 CPU min MHz 条目。

lscpu
Architecture:           x86_64
  CPU op-mode(s):       32-bit, 64-bit
  Address sizes:        39 bits physical, 48 bits virtual
  Byte Order:           Little Endian
CPU(s):                 8
  On-line CPU(s) list:  0-7
Vendor ID:              GenuineIntel
  Model name:           Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz
    CPU family:         6
    Model:              94
    Thread(s) per core: 2
    Core(s) per socket: 4
    Socket(s):          1
    Stepping:           3
    CPU(s) scaling MHz: 38%
    CPU max MHz:        4200.0000
    CPU min MHz:        800.0000
    BogoMIPS:           8003.30
    Flags:              fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtop
                        ology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3
                        dnowprefetch cpuid_fault invpcid_single pti ssbd ibrs ibpb stibp fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat p
                        ln pts hwp hwp_notify hwp_act_window hwp_epp md_clear flush_l1d arch_capabilities
Caches (sum of all):    
  L1d:                  128 KiB (4 instances)
  L1i:                  128 KiB (4 instances)
  L2:                   1 MiB (4 instances)
  L3:                   8 MiB (1 instance)
NUMA:                   
  NUMA node(s):         1
  NUMA node0 CPU(s):    0-7
Vulnerabilities:        
  Itlb multihit:        KVM: Mitigation: VMX unsupported
  L1tf:                 Mitigation; PTE Inversion
 ...
最新问题
© www.soinside.com 2019 - 2024. All rights reserved.