Bug 244674 - Unable to set CPU governor to a power profile
Summary: Unable to set CPU governor to a power profile
Status: RESOLVED INTENTIONAL
Alias: None
Product: solid
Classification: Unmaintained
Component: powermanagement-kcm (show other bugs)
Version: unspecified
Platform: openSUSE Linux
: NOR normal
Target Milestone: ---
Assignee: Dario Freddi
URL:
Keywords:
: 248762 255911 277375 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-07-14 22:57 UTC by Kristjan Ugrin
Modified: 2011-07-08 21:05 UTC (History)
7 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kristjan Ugrin 2010-07-14 22:57:43 UTC
Version:           unspecified (using Devel) 
OS:                Linux

I've customised power profiles to match my workload needs and I've assigned different CPU governors to each profile, so the system responds better at different scenarios.

However when I've upgraded to testing 4.5 (weekly updates) this functionality seems to be gone, there is no more CPU governor option under "CPU and system" tab under power profile.

Reproducible: Always

Steps to Reproduce:
- open systemsettings
- open Power Management
- select Edit profiles
- select a profile
- switch to "CPU and system" tab

Downgrading back to 4.4 brings back that functionality.
Comment 1 Kristjan Ugrin 2010-08-10 17:29:38 UTC
Same problem in final 4.5 release.
CPU governors are supported on my system:

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors 
conservative userspace powersave ondemand performance
Comment 2 GJ 2010-09-02 09:25:10 UTC
I agree. The governors need to be re-introduced as some of my profiles rely on them.
Comment 3 Cesar Garcia 2010-09-03 18:42:45 UTC
"Me too". Who removed this functionality?, using the ondemand governor by default isn't enough in a lot of cases and switching the profile was the only way that i had a high/low frequency when i needed it.
Comment 4 Ralph Moenchmeyer 2010-09-09 17:46:57 UTC
Same problem here (KDE 4.50 and 4.5.1 / RPMs from Opensuse Factory Repository). I do not understand why the power management features regarding profile settings for CPU and system have been removed.
Comment 5 Ralph Moenchmeyer 2010-09-09 18:08:37 UTC
I want to add that one of the scenarios where you want to be able to control cpu freq behaviour is when you run one or several VMware workstation guests. Under some conditions it is recommended and reasonable to run the cpu cores at full speed. That#s why I stumbled across the lack of control features in KDE 4.5. 

Up to KDE 4.4 I could control this easily when I needed it - right now with 4.5.x my systems run with adaptive cpu core frequencies all the time and I need to change BIOS settings to get a constant maximum speed behaviour of all of my 4 cores. 

Makes my life harder ...
Comment 6 Marc Cousin 2010-09-16 09:28:35 UTC
Same here. My cpu is not that powerful, and there is a very obvious difference in latency when using ondemand and performance (mostly the time taken to redraw hiddent windows, it can get near 1 second for amarok for instance, when using on-demand).

I read the thread about removing it (http://osdir.com/ml/kde-devel/2010-03/msg00053.html). From a theoretical point of view, anything else that ondemand may be useless. But I really don't know of a system where there is no difference between ondemand and performance.

The thing is, if there was no difference, and no use case, no one would have noticed this setting is gone.

Anyway, there is a way to get around this so at least please don't remove it
(I'm putting it here so other people affected by this change will find it) :
put "solid-powermanagement set cpufreq ondemand" in the 'when loading profile execute' box (changing the cpufreq for each profile of course).
Comment 7 Kristjan Ugrin 2010-09-16 14:58:01 UTC
Thank you for your suggestion, that was helpful!
Comment 8 Ralph Moenchmeyer 2010-09-25 18:22:35 UTC
After comment 6 of Marc Cousin I had a look at the discussion in the osdir.com thread  
http://osdir.com/ml/kde-devel/2010-03/msg00053.html 
and some more discussions regarding the CPU governor options for power management.  

It seems to me that due to the ideas of a few people (here of Holger Macht and also people from Red Hat) a useful and established feature of the GUI was taken away from the user. As a KDE user who regards the disappearance of a useful feature as a bug, now kindly want ask the developers for a return to the situation before the implementation of Holger Macht's patch. 

These are my points and arguments: 

1. The disappearance of a feature that was established and worked for quite a time now will be regarded as a bug by a lot of users.    

2. Personally, I think that taking away options does not reflect the freedom one expects from an Open Source system. It reminds me more of Windows or Apple and an intolerant user could regard it as a form of "brothering". I am the first to admit that a system administrator who is responsible for a machine must have and use possibilities to restrict user access to certain options - but this is a question of responsibility and admin education - and very different from a general removal of options. 

3. A basic ingredient in the discussion is the assumption that most users do not understand the implications of using options for CPU governors and power management. Quotation (H. Macht): "You should never offer those options to the user because he might not understand what the impact is." Ok, hard to swallow, but maybe there is some statistics supporting this attitude ... However, is it really the best solutions to keep the user in his assumed state of ignorance by hiding options and possibilities ? Would it not be much better to give him more information and advice, by e.g. adding some comments to the options available plus a hint that the "on demand" governor option is recommended for most cases ? 

4. The whole discussion regarding the power governor options is unfortunately reduced to the aspect of possibly wrong user expectations regarding the reduction of power consumption. (This reflects an assumption about user expectations which should be proven. Furthermore, it reflects an assumption on the impact of power governor profile settings on the power consumption. Where are the numbers and the statistics for it? I have at least one laptop where setting the cpu freq to a constant minimum enlarges the laptop's time on battery.)    

But - and more important - there are several additional aspects to take into account. Actually, not everybody used and uses the governor options just to reduce power consumption. 

I have 4 laptops (2 from Dell, one from Acer, one from HP), 2 self built Workstations and each of these machines reacts differently to the "on demand" option which now is KDE 4.5.1's default. In some laptop cases the control of the heat development, ventilators and resulting noise is even more important than power consumption. And it is simply not true that an "on demand" default setting provides an optimal solution regarding this aspects for each and every machine and user situation. I want to add that often there are more problems with laptop ventilator control under Linux than under Windows - especially for older laptops. For a user it is not important whose fault that is as long as the he/she has at least some options to control the consequences ....  

E.g. in a presentation meeting it might be much more important to reduce the ventilator noise than to have a "balanced computer power with low latency and somewhat reduced energy consumption". Therefore, the user should get control over some power management settings in a fast and easy way - as it was the case before the patch of H. Macht was implemented. 

Moreover, there are scenarios where the option of setting a constant (!) low or high frequency of the processor cores is important, e.g. with respect to virtual VMware or Vitual Box machines running on a Linux host. And in my opinion, even a standard user should be able to set such an option easily. 

5. Even in case a user is too stupid to see and control all the consequences of his way of using a system, he/she certainly likes some constancy and reliability of the GUI features he/she got accustomed to. Just taking away features reduces the reliability and useability of a GUI. And it generates problems and unnecessary efforts for the poor administrators who do the upgrade management and have to tell their users that they no longer can control their laptop settings as before. 

So, even given the fact that you can use 

"solid-powermanagement set cpufreq"

on the command line or in KDE's input field with the description "when loading profile execute", it makes life harder in a lot of cases. I personally hate writing and deploying additional scripts or setting options manually on several systems - just because someone found it good to take away options.     

Therefore, dear developers, please return to a state without the patch of Holger Macht and give the standard user a chance. Maybe, he/she behaves more reasonable than expected ? 

What about putting the CPU freq options in an "advanced" section and providing additional information about the Pros and Cons of each option?
Comment 9 Ralph Moenchmeyer 2010-09-25 18:29:13 UTC
*** This bug has been confirmed by popular vote. ***
Comment 10 Pino Toscano 2010-11-02 21:45:29 UTC
*** Bug 255911 has been marked as a duplicate of this bug. ***
Comment 11 Benedikt Ortmayr 2010-11-02 23:09:21 UTC
(In reply to comment #0)
> Version:           unspecified (using Devel) 
> OS:                Linux
> 
> I've customised power profiles to match my workload needs and I've assigned
> different CPU governors to each profile, so the system responds better at
> different scenarios.
> 
> However when I've upgraded to testing 4.5 (weekly updates) this functionality
> seems to be gone, there is no more CPU governor option under "CPU and system"
> tab under power profile.
> 
> Reproducible: Always
> 
> Steps to Reproduce:
> - open systemsettings
> - open Power Management
> - select Edit profiles
> - select a profile
> - switch to "CPU and system" tab
> 
> Downgrading back to 4.4 brings back that functionality.


yes but that isn´t a solution for future realizes, it has to work always
Comment 12 Benedikt Ortmayr 2010-11-02 23:22:48 UTC
(In reply to comment #0)
> Version:           unspecified (using Devel) 
> OS:                Linux
> 
> I've customised power profiles to match my workload needs and I've assigned
> different CPU governors to each profile, so the system responds better at
> different scenarios.
> 
> However when I've upgraded to testing 4.5 (weekly updates) this functionality
> seems to be gone, there is no more CPU governor option under "CPU and system"
> tab under power profile.
> 
> Reproducible: Always
> 
> Steps to Reproduce:
> - open systemsettings
> - open Power Management
> - select Edit profiles
> - select a profile
> - switch to "CPU and system" tab
> 
> Downgrading back to 4.4 brings back that functionality.


yes but that isn´t a solution for future realizes, it has to work always, there isn´t a reason for kde to work like Windows, i think this possibility to turn the cpufreq lower or upper is great and the normally speedstep from the kernel is not enough.

some friends who are not linux experts ask me who can they save energy and i tell them that they should turn down the cpufreq with the powermanagement of kde.


Flash and java run the cpu to high level and sometimes or always it not need this, my notebook runs to 50 degrees and the notebook from my friend runs to 75 degrees with the cpufreq govenor mine was at 45 degrees without cooling and same speed and the notebook of my friend runs at 55 degrees with cooling and his games run still stable.

so what is the reason to take this function away??????
Comment 13 Benedikt Ortmayr 2010-11-02 23:29:23 UTC
@holger macht

es ist gut gemeint aber nicht im sinne von KDE und Freedom? !!!
Comment 14 Dario Freddi 2010-11-09 17:30:54 UTC
I am closing this bug for many reasons. One of them is that upower (which is replacing HAL) no longer offers this feature, which is hence no longer managed by userspace tools (so even if we wanted to bring this feature back, we couldn't).

Please read the bug comments for other details.
Comment 15 Dario Freddi 2010-11-09 21:32:59 UTC
*** Bug 248762 has been marked as a duplicate of this bug. ***
Comment 16 Christoph Feck 2011-07-08 21:05:03 UTC
*** Bug 277375 has been marked as a duplicate of this bug. ***