1

I'm on an Acer laptop with an Intel i7-4710HQ, which is nominally clocked at 2.50 GHz/goes to 3.50 GHz with turbo boost. As soon as I can run turbostat after booting or doing a suspend/resume, it reports Bzy_MHz near enough to nominal values:

 Core     CPU Avg_MHz   %Busy Bzy_MHz TSC_MHz
   -       -     392   11.42    3436    2503
   0       0     151    4.49    3353    2504
   0       1      67    1.99    3340    2504
   1       2      96    2.84    3366    2504
   1       3     175    5.22    3350    2504
   2       4     105    3.14    3349    2504
   2       5      81    2.43    3322    2504
   3       6      46    1.38    3333    2504
   3       7    2419   70.03    3453    2496

However, this drops to 800 MHz around 40 seconds later:

 Core     CPU Avg_MHz   %Busy Bzy_MHz TSC_MHz
   -       -       8    1.01     798    2493
   0       0      12    1.55     798    2493
   0       1       1    0.16     800    2493
   1       2      21    2.65     798    2493
   1       3       9    1.11     798    2493
   2       4      15    1.84     798    2493
   2       5       1    0.08     797    2493
   3       6       3    0.40     798    2493
   3       7       2    0.29     798    2493

It's not represented here, but this persists when I load the CPU. Doing a suspend and resume or a reboot brings the frequency back up for another 40 seconds or so. The drop happens typically at 40-45 seconds but sometimes as late as 50 seconds after booting/resuming.

For reference, here is (part of) the output of cpufreq-info: (the output is identical for the other CPUs, of which there are 7)

analyzing CPU 0:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: 0.97 ms.
  hardware limits: 800 MHz - 3.50 GHz
  available cpufreq governors: performance, powersave
  current policy: frequency should be within 800 MHz and 3.50 GHz.
                  The governor "performance" may decide which speed to use
                  within this range.
  current CPU frequency is 800 MHz.

And of lscpu:

Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                8
On-line CPU(s) list:   0-7
Thread(s) per core:    2
Core(s) per socket:    4
Socket(s):             1
NUMA node(s):          1
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 60
Stepping:              3
CPU MHz:               800.097
BogoMIPS:              4988.66
Virtualization:        VT-x
L1d cache:             32K
L1i cache:             32K
L2 cache:              256K
L3 cache:              6144K
NUMA node0 CPU(s):     0-7

rdmsr gives a value of 8 for register 0x19a. This is true before and after the CPU frequency drops. (Using wrmsr to set it to 0, either before or after the frequency drops, does not affect the behaviour.)

The information you have seen was generated while I was running intel_pstate. However, disabling this at boot (such that cpufreq-info reports using the acpi_cpufreq driver) does not affect the behaviour. Setting processor.ignore_ppc=1 also does not affect the behaviour.

I'm already using the performance governor. Changing scaling_min_freq does not affect the behaviour. The behaviour is the same whether I am plugged in w/ battery charging or on battery only.

I don't typically observe a temperature above 70 degrees C, and in a number of test runs the temperature has been stable at near 65 degrees for each core when the frequency drops.

Update with requested information:

rdmsr --bitfield 15:8 -d -a 0x198 gives 33 for all CPUs after resume, and drops to 8 when the frequency drops.

rdmsr --bitfield 15:8 -d -a 0x199 gives 35 for all CPUs after resume and does not change when the frequency drops.

grep . /sys/devices/system/cpu/intel_pstate/* (after drop):

/sys/devices/system/cpu/intel_pstate/max_perf_pct:100
/sys/devices/system/cpu/intel_pstate/min_perf_pct:100
/sys/devices/system/cpu/intel_pstate/no_turbo:0

grep . /sys/devices/system/cpu/cpu0/cpufreq/* (after drop):

/sys/devices/system/cpu/cpu0/cpufreq/affected_cpus:0
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq:800000
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq:3500000
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq:800000
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_transition_latency:4294967295
/sys/devices/system/cpu/cpu0/cpufreq/related_cpus:0
/sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors:performance powersave
/sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq:800000
/sys/devices/system/cpu/cpu0/cpufreq/scaling_driver:intel_pstate
/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor:performance
/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq:3500000
/sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq:800000
/sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed:<unsupported>

All of these were obtained with the CPU loaded.

penlu
  • 11
  • Check CPU temp? Could be thermal throttling. – SomeoneSomewhereSupportsMonica Apr 25 '17 at 09:15
  • Ah yes, forgot to mention those. Updated to contain CPU temp observations. Wish that were the issue. – penlu Apr 25 '17 at 09:49
  • You have certainly done your homework before posting the question. While your system is under load, but freqs stuck at minimum could you do $ sudo rdmsr --bitfield 15:8 -d -a 0x198 and $ sudo rdmsr --bitfield 15:8 -d -a 0x199 and edit the results into your question. – Doug Smythies Apr 25 '17 at 14:48
  • Additionally could you post the outputs for grep . /sys/devices/system/cpu/intel_pstate/* and grep . /sys/devices/system/cpu/cpu0/cpufreq/* – Doug Smythies Apr 25 '17 at 15:20
  • I've added the information! – penlu Apr 25 '17 at 16:57
  • So you are asking for pstate 35 and suddenly only getting pstate 8. (the 33 is likely because all cores are active, turbostat will tell you that (if an older turbostat version, then it might need --debug)). – Doug Smythies Apr 25 '17 at 19:14
  • The only other thing I can think of is bit 0 of MSR 0x1FC. See 0x1FC related comments here – Doug Smythies Apr 25 '17 at 21:25
  • I set bit 0 of MSR 0x1fc to 0 (so that the contents of the register, for me, are 0x4005e) and my CPU has been released from its fetters. Thank you very much for your help. (I have in fact been having some charger issues lately; I guess these might then be the ultimate source of my problems?) – penlu May 05 '17 at 05:23

0 Answers0