New: powersave broken
https://bugzilla.kernel.org/show_bug.cgi?id=196263
Bug ID: 196263
Summary: powersave broken
Product: Power Management
Version: 2.5
Kernel Version: 4.11.6
Hardware: Intel
OS: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: cpufreq
Assignee: [email protected]
Reporter: [email protected]
Regression: NoRecent kernel upgrade enforces driver: intel_pstate. there the powersave governour is broken.
To verify this behaviour I emerged the biggest package available in gentoo, libreoffice
I changed to the powersave governour. Synced the portage tree and updated my system. This also included libreoffice
i7z reported maxed out cpu. Fans were spinning, fan air was quite hot, as in state ondemand or performance.
On previous kernels powersave would clock down the cpu to 1200, and the fan hardly will be recognizeable, fan air would stay in a certain lower range.
Compile timings of powersave governour iwth intel_pstate is similar to performanceor ondemand on previous kernels.
ASUS-G75VW roman # splat app-office/libreoffice-5.3.4.2
* app-office/libreoffice-5.3.4.2
Emerged at: Mo Jul 3 21:22:39 2017 Build time: 1 hour, 10 minutes, and 38 seconds
ASUS-G75VW roman # cpupower frequency-info
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: Cannot determine or is not supported. hardware limits: 1.20 GHz - 3.30 GHz
available cpufreq governors: performance powersave
current policy: frequency should be within 1.20 GHz and 3.30 GHz.
The governor "powersave" may decide which speed to use within this range.
current CPU frequency: 1.20 GHz (asserted by call to hardware) boost state support:
Supported: yes
Active: yes
3100 MHz max turbo 4 active cores
3100 MHz max turbo 3 active cores
3200 MHz max turbo 2 active cores
3300 MHz max turbo 1 active cores
ASUS-G75VW roman # uname -a
Linux ASUS-G75VW 4.11.6-gentoo-23-06-2017 #1 SMP Fri Jun 23 19:54:15 CEST 2017 x86_64 Intel(R) Core(TM) i7-3610QM CPU @ 2.30GHz GenuineIntel GNU/Linux
--
Similar timings with performance governour on older kernels with previous packages, just a few samples taken as reference
* app-office/libreoffice-5.2.7.2
Emerged at: Do Mai 11 23:32:41 2017 Build time: 1 hour, 10 minutes, and 55 seconds
* app-office/libreoffice-5.2.3.3-r1
Emerged at: Sa Dez 3 23:58:27 2016 Build time: 1 hour, 6 minutes, and 44 seconds
--
cpu, ivybridge: model name : Intel(R) Core(TM) i7-3610QM CPU @ 2.30GHz
--
current policy: frequency should be within 1.20 GHz and 3.30 GHz.
The governor "powersave" may decide which speed to use within this range.
Please fix this or revert to the old behaviour.
I expect powersave to be powersave, therefore no high cpu clocks, no hot air, no recognizeable fans.
Kernels around ~4.9.x or before are not affected in my case.
Signature · 2 lines
You are receiving this mail because: You are the assignee for the bug.
[Bug 196263] powersave broken
https://bugzilla.kernel.org/show_bug.cgi?id=196263
Rafael J. Wysocki ([email protected]) changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |NEEDINFO
CC| |[email protected]--- Comment #1 from Rafael J. Wysocki ([email protected]) --- intel_pstate "powersave" is not the powersave governor you are used to.
1. Does it help to run with intel_pstate=passive in the kernel command line?
2. Does it help to run with intel_pstate=disabled in the kernel command line?
Signature · 2 lines
You are receiving this mail because: You are the assignee for the bug.
[Bug 196263] powersave broken
In reply to [email protected]https://bugzilla.kernel.org/show_bug.cgi?id=196263
--- Comment #2 from Rafael J. Wysocki ([email protected]) --- (In reply to Rafael J. Wysocki from comment #1)
Quoted 5 lines
intel_pstate"powersave" is not the powersave governor you are used to.1. Does it help to run with intel_pstate=passive in the kernel command line?
2. Does it help to run with intel_pstate=disabled in the kernel command line?
That should be intel_pstate=disable, sorry.
Signature · 2 lines
You are receiving this mail because: You are the assignee for the bug.
[Bug 196263] powersave broken
In reply to [email protected]https://bugzilla.kernel.org/show_bug.cgi?id=196263
Zhang Rui ([email protected]) changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]
--- Comment #3 from Zhang Rui ([email protected]) --- Roman, please provide the information required in comment #1.
Signature · 2 lines
You are receiving this mail because: You are the assignee for the bug.
[Bug 196263] powersave broken
In reply to [email protected]https://bugzilla.kernel.org/show_bug.cgi?id=196263
Huaisheng ([email protected]) changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]
--- Comment #4 from Huaisheng ([email protected]) --- intel_pstate belongs to SETPOLICY implementation, acpi-cpufreq belongs to classical TARGET. To some degree intel_pstate's powersave is similar as acpi-cpufreq's ondemand.
Personally I prefer intel_pstate which offers better experience.
If reporter doesn't intend to disable intel_pstate, perhaps reporter could consider to modify max_perf_pct to minimal value as min_perf_pct. /sys/devices/system/cpu/intel_pstate/max_perf_pct
Signature · 2 lines
You are receiving this mail because: You are the assignee for the bug.
[Bug 196263] powersave broken
In reply to [email protected]https://bugzilla.kernel.org/show_bug.cgi?id=196263
Zhang Rui ([email protected]) changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEEDINFO |CLOSED
Resolution|--- |INSUFFICIENT_DATA--- Comment #5 from Zhang Rui ([email protected]) ---
Bug closed as there is no response from the bug reporter. Besides there are some justifications and workarounds provided in comment #1 and #4, please feel free to reopen it if the problem still exists with these suggestions.
Signature · 2 lines
You are receiving this mail because: You are the assignee for the bug.