New: intel_pstate does not obey min/max frequencies set by user
https://bugzilla.kernel.org/show_bug.cgi?id=86461
Bug ID: 86461
Summary: intel_pstate does not obey min/max frequencies set by
user
Product: Power Management
Version: 2.5
Kernel Version: 3.17-rc5
Hardware: All
OS: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: cpufreq
Assignee: [email protected]
Reporter: [email protected]
Regression: No# uname -a Linux aep-vaio 3.17.0-rc5 #1 SMP PREEMPT Thu Sep 18 23:13:08 YEKT 2014 x86_64 Intel(R) Core(TM) i7-2640M CPU @ 2.80GHz GenuineIntel GNU/Linu
# echo 2400000 | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_min_freq
# cpufreq-info cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to [email protected], 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.50 GHz available cpufreq governors: performance, powersave current policy: frequency should be within 2.40 GHz and 3.50 GHz. The governor "powersave" may decide which speed to use within this range. current CPU frequency is 804 MHz (asserted by call to hardware). 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.50 GHz available cpufreq governors: performance, powersave current policy: frequency should be within 2.40 GHz and 3.50 GHz. The governor "powersave" may decide which speed to use within this range. current CPU frequency is 885 MHz (asserted by call to hardware). 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.50 GHz available cpufreq governors: performance, powersave current policy: frequency should be within 2.40 GHz and 3.50 GHz. The governor "powersave" may decide which speed to use within this range. current CPU frequency is 800 MHz (asserted by call to hardware). 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.50 GHz available cpufreq governors: performance, powersave current policy: frequency should be within 2.40 GHz and 3.50 GHz. The governor "powersave" may decide which speed to use within this range. current CPU frequency is 822 MHz (asserted by call to hardware).
As you see, my attempt to force the minimum frequency to 2.4 GHz has been ignored.
Signature · 2 lines
You are receiving this mail because: You are the assignee for the bug.
[Bug 86461] intel_pstate does not obey min/max frequencies set by user
https://bugzilla.kernel.org/show_bug.cgi?id=86461
Dirk Brandewie <[email protected]> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]
--- Comment #1 from Dirk Brandewie <[email protected]> --- Can you send the output of the following commands before and after setting scaling_min_freq:
turbostat sleep 5
grep MH /proc/cpuinfo
grep . /sys/devices/system/cpu/intel_pstate/*
Signature · 2 lines
You are receiving this mail because: You are the assignee for the bug.
[Bug 86461] intel_pstate does not obey min/max frequencies set by user
In reply to [email protected]https://bugzilla.kernel.org/show_bug.cgi?id=86461
--- Comment #2 from Alexander E. Patrakov <[email protected]> --- aep-vaio turbostat # ./turbostat sleep 5
Core CPU Avg_MHz %Busy Bzy_MHz TSC_MHz SMI CPU%c1 CPU%c3
CPU%c6 CPU%c7 CoreTmp PkgTmp Pkg%pc2 Pkg%pc3 Pkg%pc6 Pkg%pc7 PkgWatt CorWatt GFXWatt
- - 32 2.47 1298 2794 0 5.02 0.04
0.00 92.47 50 50 3.79 0.02 4.49 77.75 4.43 0.74
0.45
0 0 37 2.97 1253 2794 0 6.90 0.07
0.00 90.06 50 50 3.79 0.02 4.49 77.75 4.43 0.74
0.45
0 1 33 2.11 1558 2794 0 7.77
1 2 27 3.05 895 2794 0 2.06 0.00
0.00 94.89 50
1 3 31 1.76 1763 2794 0 3.355.004419 sec
aep-vaio turbostat # grep MH /proc/cpuinfo
cpu MHz : 951.781
cpu MHz : 835.625
cpu MHz : 852.468
cpu MHz : 822.500
aep-vaio turbostat # grep . /sys/devices/system/cpu/intel_pstate/* /sys/devices/system/cpu/intel_pstate/max_perf_pct:100 /sys/devices/system/cpu/intel_pstate/min_perf_pct:22 /sys/devices/system/cpu/intel_pstate/no_turbo:0
aep-vaio turbostat # echo 2400000 | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_min_freq
2400000
aep-vaio turbostat # ./turbostat sleep 5
Core CPU Avg_MHz %Busy Bzy_MHz TSC_MHz SMI CPU%c1 CPU%c3
CPU%c6 CPU%c7 CoreTmp PkgTmp Pkg%pc2 Pkg%pc3 Pkg%pc6 Pkg%pc7 PkgWatt CorWatt GFXWatt
- - 39 1.74 2229 2794 0 4.47 0.51
0.00 93.27 53 53 4.40 0.23 5.35 77.63 4.48 0.87
0.37
0 0 48 2.42 1981 2794 0 2.50 0.61
0.00 94.47 53 53 4.40 0.23 5.35 77.63 4.48 0.87
0.37
0 1 13 0.78 1727 2794 0 4.14
1 2 45 1.84 2420 2794 0 5.66 0.42
0.00 92.08 53
1 3 50 1.93 2560 2794 0 5.575.001705 sec
aep-vaio turbostat # grep MH /proc/cpuinfo
cpu MHz : 1277.390
cpu MHz : 1711.718
cpu MHz : 1661.734
cpu MHz : 1932.875
aep-vaio turbostat # grep . /sys/devices/system/cpu/intel_pstate/* /sys/devices/system/cpu/intel_pstate/max_perf_pct:100 /sys/devices/system/cpu/intel_pstate/min_perf_pct:68 /sys/devices/system/cpu/intel_pstate/no_turbo:0
Signature · 2 lines
You are receiving this mail because: You are the assignee for the bug.
[Bug 86461] intel_pstate does not obey min/max frequencies set by user
In reply to [email protected]https://bugzilla.kernel.org/show_bug.cgi?id=86461
--- Comment #3 from Alexander E. Patrakov <[email protected]> --- Additional note: intel_pstate allows to set max_perf_pct lower than min_perf_pct. This should not be allowed.
Signature · 2 lines
You are receiving this mail because: You are the assignee for the bug.
[Bug 86461] intel_pstate does not obey min/max frequencies set by user
In reply to [email protected]https://bugzilla.kernel.org/show_bug.cgi?id=86461
--- Comment #4 from Dirk Brandewie <[email protected]> --- I looks like everything is working correctly. You have to remember that the frequencies returned by turbostat and intel_pstate are measured effective frequency over the time of the sample. Previously with acpi_cpufreq the value returned through /proc/cpuinfo and the cupfreq sysfs interface was the requested
frequency and not the actual frequency.
If you want to see that the floor for P states has actually changed you can see the requested P state with:
rdmsr -a -f15:8 0x199
The actual frequency that all cores on the processor run at is selected by the processor based on the requests for all cores.
Signature · 2 lines
You are receiving this mail because: You are the assignee for the bug.
[Bug 86461] intel_pstate does not obey min/max frequencies set by user
In reply to [email protected]https://bugzilla.kernel.org/show_bug.cgi?id=86461
--- Comment #5 from Alexander E. Patrakov <[email protected]> --- OK, the floor for the P states has indeed changed. If that MSR value corresponds to the CPU frequency in units of 100 MHz, then the value is indeed the desired one, and the bug can be closed as invalid.
Signature · 2 lines
You are receiving this mail because: You are the assignee for the bug.
[Bug 86461] intel_pstate does not obey min/max frequencies set by user
In reply to [email protected]https://bugzilla.kernel.org/show_bug.cgi?id=86461
Alan <[email protected]> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |[email protected]
Resolution|--- |INVALIDSignature · 2 lines
You are receiving this mail because: You are the assignee for the bug.
[Bug 86461] intel_pstate does not obey min/max frequencies set by user
In reply to [email protected]https://bugzilla.kernel.org/show_bug.cgi?id=86461
Len Brown <[email protected]> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |CLOSED
CC| |[email protected]Signature · 2 lines
You are receiving this mail because: You are the assignee for the bug.