Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#28778 - [linux] default to 'ondemand' as cpufreq governor

Attached to Project: Arch Linux
Opened by Tom Gundersen (tomegun) - Sunday, 04 March 2012, 22:44 GMT
Last edited by Tobias Powalowski (tpowa) - Monday, 26 March 2012, 06:45 GMT
Task Type Feature Request
Category Packages: Core
Status Closed
Assigned To Tobias Powalowski (tpowa)
Thomas B├Ąchler (brain0)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No


This was discussed before on the ML, and changed back and forth a couple of times. I have now looked into it a bit more, and would like to propose the change again.

I guess the arguments in favor are known (saves power, avoids overheating, recommended by the kernel guys, everyone else does it).

The concerns were that this is sub-optimal in some edge-cases. After looking into it again it seems not to be a problem:

* The performance problems seen in some cases have apparently been sorted out long ago.

* If you don't specifically load a driver (such as acpi-cpufreq), then you will stay at 'performance'.

* If you do load a driver, this must be because you want to change away from 'performance', so defaulting to 'performance' makes no sense. However, in the case that your driver does not support 'ondemand', it will fall back to 'performance' and work as before.

If, some time in the future, we auto-load cpufreq drivers, then I still think defaulting to 'ondemand' is correct, as only in the case of kernel bugs would you want to use something else (I can not imagine the p4 driver ever being auto-loaded considering the warnings in the kernel).
This task depends upon

Closed by  Tobias Powalowski (tpowa)
Monday, 26 March 2012, 06:45 GMT
Reason for closing:  Fixed
Additional comments about closing:  3.3 and 3.0.x series
Comment by Tobias Powalowski (tpowa) - Monday, 05 March 2012, 06:46 GMT
+1 frokm my side