Частота процессора застряла на 798 МГц.

Моя система – Debian Testing, ядро 6.11.4-amd64 на Lenovo W540. Я занимаюсь высоконадобной задачей (обработка двух больших наборов данных с использованием R), которую планировал выполнить за 26 часов. Около полуночи я решил перенести компьютер в более прохладную комнату и пойти спать. Задача была завершена на 30%. Когда я проверил утром, вместо ожидаемых 75%-80% я увидел только 35%. И тогда я понял, что частота процессора была снижена до 798 МГц вместо 2,7 ГГц, а температура процессора не превышала 40ºC. Я почти уверен, что перезагрузка исправит проблему (надеюсь) и вернет процессоры к их обычной скорости, но я не хочу тратить 20 часов времени обработки данных, поэтому все мои попытки направлены на то, чтобы не перезагружать систему.

Я предположил, что процесс отключения ноутбука, который работает от батареи, вызвал активацию функции энергосбережения. Но повторное подключение в другой комнате не восстановило полный режим производительности.

Итак, я проверил и увидел, что

root@debian:~# 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
  BIOS Vendor ID:         GenuineIntel
  Model name:             Intel(R) Core(TM) i7-4800MQ CPU @ 2.70GHz
    BIOS Model name:      Intel(R) Core(TM) i7-4800MQ CPU @ 2.70GHz  CPU @ 0.0GHz
    BIOS CPU family:      12
    CPU family:           6
    Model:                60
    Thread(s) per core:   2
    Core(s) per socket:   4
    Socket(s):            1
    Stepping:             3
    CPU(s) scaling MHz:   22%
    CPU max MHz:          3700.0000
    CPU min MHz:          800.0000
    BogoMIPS:             5387.17
    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 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 sse4_1 s
                          se4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm cpuid_fault epb pti ssbd ibrs ibpb stibp tpr_shadow flexpriority ept vpid ept_ad fs
                          gsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid xsaveopt dtherm ida arat pln pts vnmi md_clear flush_l1d
Virtualization features:  
  Virtualization:         VT-x
Caches (sum of all):      
  L1d:                    128 KiB (4 instances)
  L1i:                    128 KiB (4 instances)
  L2:                     1 MiB (4 instances)
  L3:                     6 MiB (1 instance)
NUMA:                     
  NUMA node(s):           1
  NUMA node0 CPU(s):      0-7
Vulnerabilities:          
  Gather data sampling:   Not affected
  Itlb multihit:          KVM: Mitigation: VMX disabled
  L1tf:                   Mitigation; PTE Inversion; VMX conditional cache flushes, SMT vulnerable
  Mds:                    Mitigation; Clear CPU buffers; SMT vulnerable
  Meltdown:               Mitigation; PTI
  Mmio stale data:        Unknown: No mitigations
  Reg file data sampling: Not affected
  Retbleed:               Not affected
  Spec rstack overflow:   Not affected
  Spec store bypass:      Mitigation; Speculative Store Bypass disabled via prctl
  Spectre v1:             Mitigation; usercopy/swapgs barriers and __user pointer sanitization
  Spectre v2:             Mitigation; Retpolines; IBPB conditional; IBRS_FW; STIBP conditional; RSB filling; PBRSB-eIBRS Not affected; BHI Not affected
  Srbds:                  Mitigation; Microcode
  Tsx async abort:        Not affected

root@debian:~# cpupower frequency-info
analyzing CPU 3:
  driver: intel_cpufreq
  CPUs which run at the same hardware frequency: 3
  CPUs which need to have their frequency coordinated by software: 3
  maximum transition latency: 20.0 us
  hardware limits: 800 MHz - 3.70 GHz
  available cpufreq governors: performance schedutil
  current policy: frequency should be within 800 MHz and 3.70 GHz.
                  The governor "schedutil" may decide which speed to use
                  within this range.
  current CPU frequency: Unable to call hardware
  current CPU frequency: 798 MHz (asserted by call to kernel)
  boost state support:
    Supported: yes
    Active: yes

Таким образом, процессор может работать на 3.70 ГГц, но в данный момент задействован на 22% и настроен на 798 МГц.

Я изменил настройки на ‘performance’, чтобы включить полную производительность процессора:

root@debian:~# cpupower frequency-set -g performance
Setting cpu: 0
Setting cpu: 1
Setting cpu: 2
Setting cpu: 3
Setting cpu: 4
Setting cpu: 5
Setting cpu: 6
Setting cpu: 7

Но ничего не изменилось. После проверки страницы man cpupower я попробовал установить максимальную частоту напрямую:

root@debian:~# cpupower frequency-set -f 3.70 GHz
Setting cpu: 0
Setting cpu: 1
Setting cpu: 2
Setting cpu: 3
Setting cpu: 4
Setting cpu: 5
Setting cpu: 6
Setting cpu: 7

Без всякого успеха:

root@debian:~# cpupower frequency-info
analyzing CPU 0:
  driver: intel_cpufreq
  CPUs which run at the same hardware frequency: 2
  CPUs which need to have their frequency coordinated by software: 2
  maximum transition latency: 20.0 us
  hardware limits: 800 MHz - 3.70 GHz
  available cpufreq governors: userspace performance schedutil
  current policy: frequency should be within 800 MHz and 3.70 GHz.
                  The governor "performance" may decide which speed to use
                  within this range.
  current CPU frequency: Unable to call hardware
  current CPU frequency: 798 MHz (asserted by call to kernel)
  boost state support:
    Supported: yes
    Active: yes

На этом этапе мне показалось странным, что только 2 процессора работают на одной и той же частоте, и я проверил:

root@debian:~# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor 
performance
root@debian:~# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq 
798101
root@debian:~# cat /sys/devices/system/cpu/cpu1/cpufreq/scaling_cur_freq 
798096
root@debian:~# cat /sys/devices/system/cpu/cpu2/cpufreq/scaling_cur_freq 
798092
root@debian:~# cat /sys/devices/system/cpu/cpu3/cpufreq/scaling_cur_freq 
798101
root@debian:~# cat /sys/devices/system/cpu/cpu4/cpufreq/scaling_cur_freq 
798099
root@debian:~# cat /sys/devices/system/cpu/cpu5/cpufreq/scaling_cur_freq 
798104
root@debian:~# cat /sys/devices/system/cpu/cpu6/cpufreq/scaling_cur_freq 
798097
root@debian:~# cat /sys/devices/system/cpu/cpu7/cpufreq/scaling_cur_freq 
798099

Губернатор был установлен на ‘performance’, как и ожидалось, но частота не была обновлена, и не только это, все процессоры работают на немного разных частотах.

Если я пытаюсь напрямую записать значение частоты:

root@debian:~# echo 3700000 | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq
tee: /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq: Permission denied
tee: /sys/devices/system/cpu/cpu1/cpufreq/scaling_cur_freq: Permission denied
tee: /sys/devices/system/cpu/cpu2/cpufreq/scaling_cur_freq: Permission denied
tee: /sys/devices/system/cpu/cpu3/cpufreq/scaling_cur_freq: Permission denied
tee: /sys/devices/system/cpu/cpu4/cpufreq/scaling_cur_freq: Permission denied
tee: /sys/devices/system/cpu/cpu5/cpufreq/scaling_cur_freq: Permission denied
tee: /sys/devices/system/cpu/cpu6/cpufreq/scaling_cur_freq: Permission denied
tee: /sys/devices/system/cpu/cpu7/cpufreq/scaling_cur_freq: Permission denied
3700000

Я думаю, что это значение контролируется драйвером intel_pstate, но я не нашел, как это изменить. Я также нашел утилиту intel-speed-select, но выяснилось, что

Драйверы Intel speed select не загружены в этой системе. Проверьте, включен ли параметр CONFIG_INTEL_SPEED_SELECT_INTERFACE в конфигурацию ядра. Если конфигурация включена, то это не поддерживаемая платформа.

Я не знаю, как проверить, загружен ли этот драйвер или нет, можно ли его загрузить без перезагрузки, если нет, и даже если это правильный путь для решения проблемы.

Я видел несколько аналогичных вопросов, но все предложенные решения здесь были безуспешны.

Что мне нужно, так это снова включить режим производительности без перезагрузки. Я предполагаю, что это должно быть возможно, так как противоположное произошло без перезагрузки.

ИЗМЕНЕНО:
Хотя это произошло на 30 часов позже ожидаемого, задача, которую выполнял компьютер, завершилась, и я смог сохранить результаты и перезагрузить систему.

Теперь все в порядке, и возможно, что это была единичная проблема. В любом случае, я постараюсь воспроизвести это, чтобы лучше диагностировать в выходные, на случай, если где-то есть неверная конфигурация.

Многие из моих ноутбуков Intel на протяжении многих лет переключались на ~800 МГц, когда думали, что работают от батареи, или когда “не доверяют зарядному устройству” (думают, что зарядное устройство не подает достаточно энергии для стабильной работы системы на высоких частотах, например, зарядное устройство может повредиться, подать немного энергии, но не по спецификациям, и ноутбук снижает частоту всех ядер до 800 МГц)

Попробуйте заменить зарядное устройство?