FS#31355 - [cpupower] Remove /usr/lib/pm-utils/power.d/cpupower

Attached to Project: Community Packages
Opened by Thomas Bächler (brain0) - Friday, 31 August 2012, 10:14 GMT
Last edited by Sébastien Luttringer (seblu) - Saturday, 15 September 2012, 18:23 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Sébastien Luttringer (seblu)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

The addition of the file /usr/lib/pm-utils/power.d/cpupower enables it by default. The user is not informed that the installation of cpupower messes with his power settings.

On top of that, the default behaviour is complete nonsense: It switches to 'conservative' when on battery power. On modern CPUs, you should always use the 'ondemand' governor, regardless of battery or AC.

If a user wishes such behaviour, he should add the file himself.
This task depends upon

Closed by  Sébastien Luttringer (seblu)
Saturday, 15 September 2012, 18:23 GMT
Reason for closing:  Fixed
Additional comments about closing:  cpupower 3.5-5
Comment by Sébastien Luttringer (seblu) - Friday, 31 August 2012, 11:47 GMT
This has been discussed on ml arch-dev-public here: http://mailman.archlinux.org/pipermail/arch-dev-public/2012-August/023411.html

Before adding this, I thought like you about conservative/ondemand. But reading kernel doc on conservative vs ondemand, I changed my mind. Conversative increase speed step by step where ondemand give full power when directly. So better governor for battery would be conservative.
Why do you see it differently?

About disabling, like modules in /usr/lib/modules-load.d, files are loaded by default in /usr/lib/pm-utils/power.d/. The upstream way to disable it is to put an empty file in /etc/pm/power.d, like for module-load.d, unlike systemd services.
Comment by Thomas Bächler (brain0) - Sunday, 02 September 2012, 14:20 GMT
The problem is much more subtle. "conservative" increases the speed slowly, so actions take longer, thus the CPU has to stay at a higher speed for a longer time - this draws significantly more power.

"conservative" is only meant for CPUs that can't handle the short transition times of ondemand.

BTW, the upstream way in cpupower is not to provide this file. Arch should follow this.
Comment by Dave Reisner (falconindy) - Sunday, 02 September 2012, 14:29 GMT
The default behavior should be what upstream ships. I see no reason to ship our own defaults on top of that.
Comment by Thomas Bächler (brain0) - Sunday, 02 September 2012, 14:37 GMT
Dave also found this link, which explains my point much more clearly: http://www.lesswatts.org/projects/applications-power-management/race-to-idle.php
Comment by Thomas Bächler (brain0) - Sunday, 02 September 2012, 14:39 GMT
Dave comes up with all the links that I failed to find. This is the original blog post I read years ago about power saving: http://mjg59.livejournal.com/88608.html
Comment by Tom Gundersen (tomegun) - Sunday, 02 September 2012, 15:00 GMT
My bad for forwarding this from Jan to Sébastien without looking at it.

Having read the file, I agree with Thomas: We should never default to anything else than on-demand (which is why I pushed to change our default to that in the kernel some time ago). Users might want to do other things in special cases (weird/broken hardware,++), but that should be done on a case-by-case basis only.
Comment by Jan Alexander Steffens (heftig) - Monday, 03 September 2012, 09:49 GMT
I have no particular attachment to any policy. I just ported the cpufreq hook to cpupower.

Loading...