Providing a D-Bus interface for CPUFreq knobs
There has been a discussion on the HAL development list regarding DeviceKit, a corresponding power management subsystem daemon, and a possible CPU frequency scaling interface.
During the discussion, it turned out, and I realised this quite late, that KPowersave still exports the possibility to set either the powersave or performance governor. That is basically a bad idea, and still there because of former times. See this journal for a good rationale. However, the author quite unfriendly rants towards the developers. Unfortunately, I've not seen a bugreport in sourceforge's bugtracker for that, nor anywhere else. Maybe he could have pointed this out in a more elegant way, instead of immediately telling people they are dangerous. How emotional. And funny after all. I filed it here, just to be sure it is not missed for upcoming openSUSE 11.0.
So that is the one issue of the discussion, a completely other one is about if we need a D-Bus interface for tuning CPU frequency scaling (related to the ondemand governor) knobs. As an example, the ondemand governor provides an upthreshold setting you can tune through sysfs. Basically it defines how long a CPU burst has to be so that the frequency is increased. Quoting the kernel documentation:
upthreshold: defines what the average CPU usaged between the samplings of 'samplingrate' needs to be for the kernel to make a decision on whether it should increase the frequency. For example when it is set to its default value of '80' it means that between the checking intervals the CPU needs to be on average more than 80% in use to then decide that the CPU frequency needs to be increased.
When having only short CPU bursts, it is better to stay at a low frequency for a short period of time when it comes down to power consumption. And the typical desktop use consists of those short CPU bursts. Browsing a web page, opening a mail folder, etc.
The kernel sets a sane default for this setting. It is nearly self-evident for a default to be sane, someone should have thought carefully about it. However, that does not mean it is ideal. It just cannot be for all different kind of use cases. Servers, desktops, what applications are running, "on battery", "on AC", namely, depending on the current power source.
So I am an advocator of having a D-Bus interface somewhere at the system level (we already have in HAL, but this will most likely vanish sooner or later due to its successor called DeviceKit) for tuning such knobs by someone who cares about policy. And policy is more and more put to Desktop applications these days.
blog comments powered by Disqus