1

The cpu frequency scaling on my laptop (Intel(R) Core(TM) i7-4810MQ CPU @ 2.80GHz) is not working as intended. After the initial installation of ubuntu 16.04 I have made no changes regarding power management or the cpu frequency scaling. Normally I am used to the ondemand governor. However, it seems this governor was replaced with some pstate thingy and the powersave governor in newer kernels.

Even without load the cpu frequencies hover around the 2.x range thus causing the fans to be noisy and the device to heat up:

$ cat /proc/cpuinfo |grep -i mh
cpu MHz     : 3435.468
cpu MHz     : 2245.468
cpu MHz     : 2800.218
cpu MHz     : 2338.765
cpu MHz     : 2800.546
cpu MHz     : 2801.203
cpu MHz     : 2800.875
cpu MHz     : 2000.140
$ uptime
 14:57:49 up  5:15,  1 user,  load average: 0,01, 0,08, 0,16
$ cpufreq-info 
cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to cpufreq@vger.kernel.org, please.
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.80 GHz
  available cpufreq governors: performance, powersave
  current policy: frequency should be within 800 MHz and 3.80 GHz.
                  The governor "powersave" may decide which speed to use
                  within this range.
  current CPU frequency is 2.80 GHz.
analyzing CPU 1:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 1
  CPUs which need to have their frequency coordinated by software: 1
  maximum transition latency: 0.97 ms.
  hardware limits: 800 MHz - 3.80 GHz
  available cpufreq governors: performance, powersave
  current policy: frequency should be within 800 MHz and 3.80 GHz.
                  The governor "powersave" may decide which speed to use
                  within this range.
  current CPU frequency is 2.80 GHz.
analyzing CPU 2:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 2
  CPUs which need to have their frequency coordinated by software: 2
  maximum transition latency: 0.97 ms.
  hardware limits: 800 MHz - 3.80 GHz
  available cpufreq governors: performance, powersave
  current policy: frequency should be within 800 MHz and 3.80 GHz.
                  The governor "powersave" may decide which speed to use
                  within this range.
  current CPU frequency is 2.79 GHz.
analyzing CPU 3:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 3
  CPUs which need to have their frequency coordinated by software: 3
  maximum transition latency: 0.97 ms.
  hardware limits: 800 MHz - 3.80 GHz
  available cpufreq governors: performance, powersave
  current policy: frequency should be within 800 MHz and 3.80 GHz.
                  The governor "powersave" may decide which speed to use
                  within this range.
  current CPU frequency is 2.80 GHz.
analyzing CPU 4:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 4
  CPUs which need to have their frequency coordinated by software: 4
  maximum transition latency: 0.97 ms.
  hardware limits: 800 MHz - 3.80 GHz
  available cpufreq governors: performance, powersave
  current policy: frequency should be within 800 MHz and 3.80 GHz.
                  The governor "powersave" may decide which speed to use
                  within this range.
  current CPU frequency is 2.80 GHz.
analyzing CPU 5:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 5
  CPUs which need to have their frequency coordinated by software: 5
  maximum transition latency: 0.97 ms.
  hardware limits: 800 MHz - 3.80 GHz
  available cpufreq governors: performance, powersave
  current policy: frequency should be within 800 MHz and 3.80 GHz.
                  The governor "powersave" may decide which speed to use
                  within this range.
  current CPU frequency is 2.78 GHz.
analyzing CPU 6:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 6
  CPUs which need to have their frequency coordinated by software: 6
  maximum transition latency: 0.97 ms.
  hardware limits: 800 MHz - 3.80 GHz
  available cpufreq governors: performance, powersave
  current policy: frequency should be within 800 MHz and 3.80 GHz.
                  The governor "powersave" may decide which speed to use
                  within this range.
  current CPU frequency is 2.90 GHz.
analyzing CPU 7:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 7
  CPUs which need to have their frequency coordinated by software: 7
  maximum transition latency: 0.97 ms.
  hardware limits: 800 MHz - 3.80 GHz
  available cpufreq governors: performance, powersave
  current policy: frequency should be within 800 MHz and 3.80 GHz.
                  The governor "powersave" may decide which speed to use
                  within this range.
  current CPU frequency is 2.79 GHz.

Curiously enough I've also observed the reverse behavior: the machine was under high load but the frequencies were being decreased until after ca. 20-30sec all cores reached ~ 800MHz. I checked with cpufreq-info and the configuration seemed fine (powersave governor, min/max freq at appropriate levels). Sadly I am unable to reproduce the error...

Any idea what causes these scaling issues or what could be done to fix them?

  • I have the same problem, reverse scaling!!! I'm using Ubuntu 18.04 in a i7-7Y75 cpu. When idle it scales to 3,2 Ghz, while idle it's 800 Mhz. – Philippe Delteil May 25 '18 at 17:53
0

Summary

Yes, under certain conditions the current version of the intel_pstate driver can drive up the CPU frequency under fairly light loads. However, and typically, this would NOT cause the "fans to be noisy and the device to heat up", because the related CPUs do their work quicker and therefore spend more time in deep sleep states, counteracting the higher active power. I have only ever been able to attribute approximately an extra 1/2 watt of package power to this issue.

As for the second part of your question, about decreasing CPU frequencies under high load. I can only assume that some sort of thermal throttling is involved.

Details

It is very important to define "without load", or "idle". Why? Because on a GUI based system, "idle" actually has a considerable amount of work to do. On a non-GUI server based system, "idle" typically really means there is very little work to do.

On GUI based systems, manifestation of this issue depends on: The Hz rate of the kernel (100, 250, 300, or 1000 Hz); The frame rate of the video driver; How much background stuff is going on; The way the scheduler rotates between CPUs; Some other things that I forget at the moment.

While a temporary fix has been added, it only covers actual loads of 1% or less, but the condition can also occur for loads over 1%. Also I do not know if that fix is in, or has been backported, to the current 16.04 kernel.

A better fix is in progress, but it will be sometime before it is released.
In the meantime, and if desired you can go back to the acpi-cpufreq driver. See here or here for how.

References

https://bugzilla.kernel.org/attachment.cgi?id=187781
https://bugzilla.kernel.org/show_bug.cgi?id=93521
https://bugzilla.kernel.org/show_bug.cgi?id=115771
http://marc.info/?l=linux-pm&m=147000845531378&w=2
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ffb810563c0c049872a504978e06c8892104fb6c

  • Ok nice! Thank you for the quick and detailed answer! Especially the links to the kernel bug reports are very helpful! – dassmann Aug 16 '16 at 11:22
  • @dassmann: If you want to look into your case specifically, then I would need an approximately 300 second trace acquired when your system is "idle" ( sudo perf record -a --event=power:pstate_sample sleep 300 ). If so, it would be best to continue on bug 93521. – Doug Smythies Aug 16 '16 at 23:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.