kde-guidance-powermanager: support "conservative" CPUFreq gouvernor

[David Gaarenstroom]

Binary package hint: kde-guidance-powermanager

kde-guidance-powermanager lacks support for the "conservative" CPU frequency gouvernor. It is preferable above "ondemand" when running on battery.

A patch proposal wil follow.

[Sebastian Kügler (sebasje)]

Hi David,

First, thanks for the patch. There are some tab/space issues in there, this *might* work, but it's broken -- don't mix space with tabs in python scripts.

As to the actual functionality: I'm inclined to not merge it. Powermanager should be kept simple, we decided (together with usability folks) that we don't want a one-to-one mapping of cpufreq governors with cpu frequency policies. Instead, we decided to offer dynamic (basically what ondemand does), performance and powersave. I think adding "conservative" would be confusing to the user.

Cheers,
--
sebas

[David Gaarenstroom (david-gaarenstroom)]

Hi Sebas,

Odd, kate shows no spaces/tabs inconsistencies at all... As a python hacker I know how important this is. Maybe a upload/download bug?
(The only thing I can find is some trailing spaces on the original and existing trivial inconsistencies... ;-) )

Anyway, I agree Powermanager should be kept simple. However, I don't but that does not mean you should ignore the "conservative" governor. I propose this change:
On AC, use ['dynamic', 'conservative', 'userspace'] in that order.
On Battery, use ['conservative', 'dynamic', 'userspace'] in that order.

Greetings,
David

[David Gaarenstroom (david-gaarenstroom)]

FYI, "conservative" is a dynamic governor optimized for battery usage. "ondemand" is a dynamic governor optimized for AC usage... IMHO, it's no loss using "conservative" on AC power. On battery, when using "ondemand" instead of "conservative" on my laptop, it costs me at least half an hour of battery time!

[Sebastian Kügler (sebasje)]

Hi David,

The lines starting with "action" use tabs (but as you state, there is some inconsistency in the released code as well (it's fixed in SVN already, that's also why I double-checked).

I do not understand your rationale, however. For example:

- Why should we use 'userspace' at all (there is no option to set the cpufrequency directly, which is the whole point of that governor)
- What is the advantage of 'conservative' over 'powersave' (I guess that would be the easiest to follow path)?

Cheers!

[David Gaarenstroom (david-gaarenstroom)]

- We seem to be using "userspace" at the moment as a fallback for ondemand (see powermanage.py). Removing this is out of the scope of this bug/feature-request.
- "powersave" is not a dynamic governor, it is plain the slowest frequency possible. (In contrary to Performance, which is plain the fastest frequency).

See Documentation/cpu-freq/governors.txt in any recent kernel:
------
The CPUfreq governor "conservative", much like the "ondemand"
governor, sets the CPU depending on the current usage. It differs in
behaviour in that it gracefully increases and decreases the CPU speed
rather than jumping to max speed the moment there is any load on the
CPU. This behaviour more suitable in a battery powered environment.
------

[Sebastian Kügler (sebasje)]

On Monday 23 April 2007 16:35:53 DavidG wrote:
> FYI, "conservative" is a dynamic governor optimized for battery usage.
> "ondemand" is a dynamic governor optimized for AC usage... IMHO, it's no
> loss using "conservative" on AC power. On battery, when using "ondemand"
> instead of "conservative" on my laptop, it costs me at least half an
> hour of battery time!

So the following would make sense:

- user setting 'dynamic'
- we use to 'ondemand' on AC
- we use 'conservative' on battery

What do you think about this?
--
sebas

[David Gaarenstroom (david-gaarenstroom)]

that's fine with me. It wouldn't hurt either to use "conservative" in both situations, but I'd prefer to use "ondemand" on AC.

Who writes the patch?

[Sebastian Kügler (sebasje)]

On Monday 23 April 2007 20:46:21 DavidG wrote:
> that's fine with me. It wouldn't hurt either to use "conservative" in
> both situations, but I'd prefer to use "ondemand" on AC.
>
> Who writes the patch?

You asked for it :-)

I've some serious time constraints at the moment, so it would take some time.
I can help with testing, of course. (Which I would have to do anyway.)

Just privmail me for further details (sebas kde org).
--
sebas

[Luka Renko (lure)]

I would agree that David's proposal is fine, so we would only redefine the meaning of Dynamic to try the following modes (in this order):
- on AC: ondemand, conservative, userspace
- on battery: conservative, ondemand, userspace

I can work on this patch for Feisty+1 (probably in next day or two).

[David Gaarenstroom (david-gaarenstroom)]

I can do it too, I just wanted to prevent that two people write a different version of the same patch...

[Yuriy Kozlov (yuriy-kozlov)]

Did this ever get done? Why is it invalid?

[Scott Kitterman (kitterman)]

Needs to get moved to the KDE4 port and looked at. No, it never got done.

[Fernando Miguel (fernandomiguel)]

According to Matthew Garrett (http://mjg59.livejournal.com/88608.htm) the default should be to not set any other profile other then ondemand.

[Fernando Miguel (fernandomiguel)]

According to Matthew Garrett (http://mjg59.livejournal.com/88608.html) the default should be to not set any other profile other then ondemand.

[David Gaarenstroom (david-gaarenstroom)]

The cpufreq developers disagree on that. And I strongly disagree on that. On my notebook, 1000MHz is a lot faster that 800MHz, because it makes the memory clock and access-time much faster. It's not just the CPU that scales up.

But anyone should understand that conservative is still better that performance. At least when I filed the bug, either ondemand, userspace, performance or powersave was the cpufreq policy for "dynamic" in that order.

[Fernando Miguel (fernandomiguel)]

David I share your view, but there seems to be much new information showing it other wise.
I'll try to measure my power drain and battery duration to see if I can get a better view on this subject.

[David Gaarenstroom (david-gaarenstroom)]

The most important point of this bugreport was to get conservative support into guidance-power-manager, not necessarily as the preferred-over-ondemand one. But without ondemand, conservative should be the alternative, not powersave as that is not a dynamic cpufreq policy at all.

[David Gaarenstroom (david-gaarenstroom)]

I was hesitating a bit, but apparently this bug has been fixed, conservative is now considered a "dynamic" cpufreq policy.