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_latencydoesn'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_latencyevery time?
P.S. This is a laptop and the BIOS configuration is very basic and does not allow configuration of C-states.
CPU not transitioning into higher C states
Aucun commentaire:
Enregistrer un commentaire