jeudi 9 février 2017

CPU not transitioning into higher C states

Vote count: 0

An issue that has been bugging me for a while now is that my computer's CPU for some reason refuses to go to higher C-states when idle and stays almost exclusively in C1, as shown from the sample output of i7z below:

Socket [0] - [physical cores=2, logical cores=4, max online cores ever=2]
  TURBO ENABLED on 2 Cores, Hyper Threading ON
  Max Frequency without considering Turbo 2690.65 MHz (99.65 x [27])
  Max TURBO Multiplier (if Enabled) with 1/2/3/4 Cores is  31x/30x/30x/30x
  Real Current Frequency 539.35 MHz [99.65 x 5.41] (Max of below)
        Core [core-id]  :Actual Freq (Mult.)      C0%   Halt(C1)%  C3 %   C6 %  Temp      VCore
        Core 1 [0]:       539.35 (5.41x)        3.25    95.7       1     2.6    41      0.7229
        Core 2 [1]:       511.70 (5.13x)        1.73    84.7       1      14    40      0.7222

For reference, the CPU is an Intel Core i7-6500U (Skylake) running Gentoo Linux with kernel version 4.9.6. This is also the case when booting Debian Testing with kernel version 4.9.0.

After doing some research I found that the current maximum allowed DMA latency imposes restrictions on the highest C-state that can be entered.

Looking at the information in /sys/devices/system/cpu/cpu0/cpuidle/stateN/(name|latency) I could infer the following transition table where latency is specified in µsec.

+-------------------+
| State   | Latency |
|---------+---------|
| POLL    | 0       |
| C1-SKL  | 2       |
| C1E-SKL | 10      |
| C3-SKL  | 70      |
| C6-SKL  | 85      |
| C7s-SKL | 124     |
| C8-SKL  | 200     |
| C9-SKL  | 480     |
| C10-SKL | 890     |
+-------------------+

Having found this article I was able to set the maximum allowed DMA latency by writing the latency time to /dev/cpu_dma_latency. A value of 1068=7010 successfully allowed the CPU to transition to state C3 when idle. Similarly, writing a value of 17508=100010 allowed the CPU to transition to all the higher C-states.

Switching drivers from intel_pstate to acpi_cpufreq as well as from intel_idle to acpi_idle made no difference.

Finally, the questions that arose along the way are:

  • Where does the default value for the CPU DMA latency come from? A wild guess tells me it might have something to do with the BIOS/UEFI firmware and/or the CPU microcode but I am not sure.
  • How can one read the current DMA latency? Reading from /dev/cpu_dma_latency doesn't seem to be consistent with the value previously set.
  • Is there any other way to have this issue resolved without having to write to /dev/cpu_dma_latency every time?

P.S. This is a laptop and the BIOS configuration is very basic and does not allow configuration of C-states.

asked 9 secs ago

Let's block ads! (Why?)



CPU not transitioning into higher C states

Aucun commentaire:

Enregistrer un commentaire