Matthew Garrett ([info]mjg59) wrote,
@ 2008-11-23 14:24:00
Previous Entry  Add to memories!  Tell a Friend  Next Entry
Entry tags:advogato, fedora

Making sure we do power management the right way
I saw a posting about PowerDevil, the new KDE power management interface. It's somewhat disheartening - for the most part, it falls into the same traditional errors made in power management (ie, letting you change cpufreq settings, using "presentation" as a power management setting rather than getting applications to actually do the right thing). But my point isn't to bitch about PowerDevil. My concern is more about why we're still failing to get the message across about certain power management myths. Implementing power management incorrectly leads to wasted power, dead polar bears and wet carpets. It's important that we get this right.

  • To a first approximation, the Powersave governor will only save you power if you're playing 3D games. The performance governor will basically never give you extra performance. Don't use them. Use ondemand instead. Do not make it easy for your users to choose them. They will get it wrong, because it is difficult to explain why this result is true.
  • Thermal management is not the job of a power manager. Using power management to implement thermal management will result in your computer taking up more power overall, reducing battery life. Implement things in the right places.
  • When people say "Presentation mode", what they mean is "Disable screensaver and automatic suspend to RAM". This is not a power management policy. It is an application behaviour policy. The sensible behaviour is for applications to request that these things be disabled when they switch to full-screen presentation mode. The foolish behaviour is to request that your users select "Presentation mode" in their desktop and then start their presentation in their application and then finish their application and then remember to disable "Presentation mode".
  • It takes no more energy to scan out a framebuffer drawn with the 3D engine than with the 2D engine. If you're spending a significant proportion of the time on the GPU when in your desktop environment, you're already doing something wrong.
One of the problems is probably that most desktop programmers don't know how hardware behaves. How can we change that?



(72 comments) - (Post a new comment)

Spending time in the GPU
(Anonymous)
2008-11-23 03:47 pm UTC (link)
I thought that we should be moving closer toward drawing the desktop in the GPU rather than wasting CPU time on doing graphics. The GPU is generally faster than the CPU at graphics operations...

I know faster != less power usage but surely a GPU would be less power hungry doing things like cairo than the CPU, in certain circumstances.

We're hoping to offload our entire desktop to the GPU (which is the way the new gnome shell is going) this seems to play counter to what you're saying. Could you elaborate on this?

BR,
Karl Lattimer
(still trying to figure out how to use OpenID)

(Reply to this) (Thread)

Re: Spending time in the GPU
[info]mjg59
2008-11-23 03:52 pm UTC (link)
Right. But if your desktop environment is spending significant amounts of time drawing, you're already failing from a power management standpoint. Using the GPU is preferable to using the CPU, but you should be doing neither.

(Reply to this) (Parent)(Thread)

Re: Spending time in the GPU - (Anonymous), 2008-11-23 04:11 pm UTC

(Anonymous)
2008-11-23 03:48 pm UTC (link)
What about when the application crashes? VLC crashes very often for me, leaving me with my screensaver disabled

(Reply to this) (Thread)


[info]mjg59
2008-11-23 03:53 pm UTC (link)
Fix the application, don't bodge your entire desktop environment!

(Reply to this) (Parent)(Thread)

(no subject) - [info]hub_, 2008-11-23 04:26 pm UTC

(Anonymous)
2008-11-23 04:05 pm UTC (link)
Yes, I've got into the habit of just disabling the (KDE) screensaver at all and instead manually switching off the display. The screensaver just doesn't start anymore after a while, so no use in relying on it. Ok, this is probably not a big problem for more "normal" users as they log off anyway at the end of the day :-)

AFAIK with xscreensaver the video player apps had to re-disable the screensaver every few minutes, so a crashed app wouldn't disable it forever. Apparently KDE doesn't require this, but I wonder if the devs even thought about this problem.

(Reply to this) (Parent)(Thread)

(no subject) - [info]lionsphil, 2008-11-23 04:45 pm UTC
(no subject) - (Anonymous), 2008-11-23 10:31 pm UTC

[info]dgh
2008-11-24 11:04 pm UTC (link)
If it's inhibiting suspend via D-Bus, the correct solution is for the thing that does the suspend to keep track of which clients inhibit suspend, and to uninhibit suspend when it notices those clients falling off the bus.

(Reply to this) (Parent)

A good start
(Anonymous)
2008-11-23 03:51 pm UTC (link)
I think spreading insightful posts like yours might be a good start :)

(Reply to this) (Thread)

Re: A good start
(Anonymous)
2008-11-24 07:24 am UTC (link)
Even better start would be checking if application he is bashing actually commits those errors. This way his post could be actually insightful instead of clueless rant.

(Reply to this) (Parent)(Thread)

Re: A good start - [info]mjg59, 2008-11-24 01:31 pm UTC
how to control the heat then?
(Anonymous)
2008-11-23 03:53 pm UTC (link)
I change CPU rather often because sometimes I just do not want my laptop to be so heated and do not mind if it is a little bit slower. How would it be possible to implement this functionality differently?

(Reply to this) (Thread)

Re: how to control the heat then?
[info]mjg59
2008-11-23 03:57 pm UTC (link)
Monitor the temperature and adjust the maximum frequency as appropriate. There's no point in limiting the maximum frequency when you're below your maximum temperature - doing so just wastes power. If you mean "How do you do this with current software", then you can't. That's not an excuse for writing software that does it the wrong way.

(Reply to this) (Parent)(Thread)

Re: how to control the heat then? - (Anonymous), 2008-11-23 07:20 pm UTC
Re: how to control the heat then? - [info]mjg59, 2008-11-23 07:36 pm UTC
Re: how to control the heat then? - (Anonymous), 2008-11-23 07:51 pm UTC
Get you facts straights
[info]bjacob
2008-11-23 04:09 pm UTC (link)
So, bashing KDE is so much fun that you won't even care to get your facts before posting?

The "Power profile" as exposed in PowerDevil is NOT the cpu governor.

Here on my machine, PowerDevil says "Power Profile: Performance" but cpufreq/scaling_governor says "ondemand".

For your information, the Power profile in PowerDevil determines things like e.g. screen brightness (goes darker as battery enters critical low level).

And, having an explicit "Presentation" mode doesn't mean that KDE apps can't request it automatically, or that KDE developers wouldn't agree that it is desirable to have it switched automatically; rather, it means that you can enable presentation mode even if your app doesn't support it. So what is it you're bitching about ??

(Reply to this) (Thread)

Re: Get you facts straights
(Anonymous)
2008-11-23 04:36 pm UTC (link)
If one person takes things the wrong way, your UI is broken, especially when it's someone as well respected as Matthew.

(Reply to this) (Parent)(Thread)

Re: Get you facts straights - [info]bjacob, 2008-11-23 04:44 pm UTC
Re: Get you facts straights
[info]mjg59
2008-11-23 04:36 pm UTC (link)
What? I didn't say that the power profile was the cpu governor. What I said was that Powerdevil exposed an interface to set the cpu governor. Which it does.

And if your application doesn't support disabing the screensaver, add support. It's really not hard.

(Reply to this) (Parent)(Thread)

Re: Get you facts straights - [info]bjacob, 2008-11-23 04:47 pm UTC
Re: Get you facts straights - [info]mjg59, 2008-11-23 05:07 pm UTC
Re: Get you facts straights - [info]randomguy3.wordpress.com, 2008-11-23 05:16 pm UTC
Re: Get you facts straights - [info]mjg59, 2008-11-23 05:21 pm UTC
Re: Get you facts straights - [info]bjacob, 2008-11-23 05:22 pm UTC
Re: Get you facts straights - [info]bjacob, 2008-11-23 05:29 pm UTC
Re: Get you facts straights - [info]mjg59, 2008-11-23 05:33 pm UTC
Re: Get you facts straights - [info]Einar [myopenid.com], 2008-11-23 06:52 pm UTC
Re: Get you facts straights - [info]mjg59, 2008-11-23 07:09 pm UTC
Re: Get you facts straights - [info]Einar [myopenid.com], 2008-11-23 08:49 pm UTC
Re: Get you facts straights - [info]mjg59, 2008-11-23 09:17 pm UTC
Re: Get you facts straights
[info]ajaxxx
2008-11-23 04:45 pm UTC (link)
Part of the reason bashing KDE is fun is it's so easy to do, because KDE fans have this great Pavlovian foam-at-the-mouth response.

Cough.

So if it doesn't let you control the CPU governor, why show the list of candidate governors in the UI? All that can possibly do is make someone want to try a bad one.

(Reply to this) (Parent)(Thread)

Re: Get you facts straights - [info]bjacob, 2008-11-23 04:49 pm UTC
Re: Get you facts straights - [info]lionsphil, 2008-11-23 06:50 pm UTC
Re: Get you facts straights - [info]Einar [myopenid.com], 2008-11-23 08:50 pm UTC
Re: Get you facts straights - [info]mjg59, 2008-11-23 09:16 pm UTC
Re: Get you facts straights - [info]lionsphil, 2008-11-23 09:49 pm UTC

(Anonymous)
2008-11-23 04:29 pm UTC (link)
Please fix ondemand to not fail hard in certain common corner cases before advocating the killing of cpufreq interfaces, leaving users in the cold when they get into a situation where ondemand fails completely. Like in the very "uncommon" case of watching a high-def movie. Still need to restore cpufreq stuff in gnome-power-manager because it was unfoundly killed.

(Reply to this) (Thread)


[info]mjg59
2008-11-23 04:37 pm UTC (link)
Got a precise test case?

(Reply to this) (Parent)(Thread)

(no subject) - (Anonymous), 2008-11-23 04:47 pm UTC
(no subject) - (Anonymous), 2008-11-23 04:52 pm UTC
(no subject) - [info]mjg59, 2008-11-23 05:02 pm UTC
(no subject) - (Anonymous), 2008-11-23 05:04 pm UTC
(no subject) - [info]mjg59, 2008-11-23 05:08 pm UTC
(no subject) - (Anonymous), 2008-11-23 05:10 pm UTC
(no subject) - [info]mjg59, 2008-11-23 05:16 pm UTC
(no subject) - (Anonymous), 2008-11-23 05:24 pm UTC
(no subject) - [info]mjg59, 2008-11-23 05:33 pm UTC
(no subject) - (Anonymous), 2008-11-23 05:08 pm UTC
(no subject) - (Anonymous), 2008-11-24 01:12 am UTC
(no subject) - (Anonymous), 2008-11-24 03:47 am UTC

[info]lionsphil
2008-11-23 04:37 pm UTC (link)
What, you don't like horrible interface lag?

Linux seems to be really reluctant to floor the processor these days. Can has scrolling which doesn't spend the first second in stutter-city plz?

(Reply to this) (Parent)

A Guide to Linux Power Saving
(Anonymous)
2008-11-23 06:39 pm UTC (link)
Do this: http://0pointer.de/blog/projects/guide-to-sound-apis.html -- for powersaving.

Put things from the *developer's* point of view (instead of PowerDevil's tactic of putting it from the user's point of view).

Questions to answer:

How do I maximize CPU performance?
How do I maximize power saving?
How do I inhibit screensaver/sleeping?
etc. etc.

If something like this could live on a wiki at freedesktop.org, then developers from every point in the stack (kernel, desktop environment) could comment.

(Reply to this)

In case you didn't see..
(Anonymous)
2008-11-23 06:52 pm UTC (link)
http://vizzzion.org/?blogentry=836

(Reply to this) (Thread)

Re: In case you didn't see..
(Anonymous)
2008-11-24 09:53 am UTC (link)
^ Cool link, dude.

Another Anonymous :)

(Reply to this) (Parent)

cpufreq governor is also a latency question
(Anonymous)
2008-11-23 07:07 pm UTC (link)
No dynamic cpufreq governor can be perfect. You can always optimize either for less power consumption or less latency. And there will always be some latency because the governors try to foresee the future by looking at the past. The amount of time they look into the past defines the switching latency. This time can be reduced, but then you become sub-optimal with regards to power consumption, which is bad for the polar bears, or you end up with oscillation.

The mplayer case it not an exception. Given a switching latency and knowledge of the algorithm you can by definition construct an infinite amount of cases where the governors algorithm causes catastrophic behaviour (oscillation). Of course you can then tweak the algorithm parameters to avoid a special case, but eradicating them all is not trivial.

The ondemand governor is indeed good for many use cases, but not for all of them. It's a good default if you have no knowledge about what's actually required. But you need to allow using a different governor when necessary.

The user might not be the perfect differentiator, however latency on the desktop is the users perception, and unless you can establish a framework for applications to report their specific requirements and make mplayer (well, every application in fact) use it, the user is the only differentiator.

As far as KDE is concerned, there could be a line inside the each .desktop file to tell the power manager about the requirements of the associated application. It is doubtful however that this feature will not be abused, because many developers won't understand it, just like regular users.

(Reply to this)

Yes, but what about other devices?
[info]bpineau
2008-11-23 07:16 pm UTC (link)
Also, correct me if I'm wrong, but there's still a few thing that can't be made "optimal by default for everybody".

Like, say, activating Sata ALPM (good for those who want to save power, bad for those needing hotplug).

Or force-enabling USB autosuspend at the risk of breaking some hardware support (until someone try to actually test and fix the thousands of usb drivers to know if we can have "supports_autosuspend=1", but for now only a small handfull of drivers do have this setting).

Or increseasing pdflush data writeback (risking a larger data loss in case of crash, but saving some power).

Or even, killing bluetooth when you know you won't need it for some time.

Right?

(Reply to this) (Thread)

Re: Yes, but what about other devices?
[info]mjg59
2008-11-23 07:24 pm UTC (link)
Right. There are some things that are more use-case driven. And coming up with good approaches to deal with whether or not people are willing to lose the functionality in order to save power is awkward. That's actually something I'm working on right now.

(Reply to this) (Parent)

ondemand vs performance on Nokia Internet Tablets
[info]mgedmin
2008-11-23 08:04 pm UTC (link)
There's an application called 'liqbase' in the Maemo Extras-Devel repository. It implements a rather snappy and smooth user interface for Nokia Internet Tablets. On a N810 the speed and responsiveness of the UI is very noticeably improved if you switch from 'ondemand' to 'performance'.

(Reply to this) (Thread)

Re: ondemand vs performance on Nokia Internet Tablets
[info]mjg59
2008-11-23 08:25 pm UTC (link)
Interesting. Most of my experience is with x86, so there's certainly the possibility that some embedded hardware will have different tradeoffs. I'll look into what the expected behaviour of the Arm stuff is. Thanks for the observation!

(Reply to this) (Parent)

Performance governor is necessary for predictability
(Anonymous)
2008-11-24 12:00 am UTC (link)
You are correct that the performance governor typically won't give you more performance. The issue is that it will give you predictable performance. If you are doing any sort of benchmarking or profiling work, you want to keep your CPU pegged to a single frequency to keep the number of variables down to a minimum. Another use case is any sort of software which automatically tunes its algorithms for a given machine. Say, for example, you are building an updated version of the Atlas BLAS. The build process will perform thousands of micro-benchmarks to choose the particular implementation that is optimal for your machine. But if you allow the ondemand governor to vary CPU frequency during the benchmark run, the results will be unpredictable, and you will end up with a sub-optimal build - not a good thing if you are running a large simulation.

You are correct that 90% of users (those who are not playing resource-intensive games, profiling their apps, running benchmarks, or using Linux for a home theater system) are better off using the ondemand governor. And that means that ondemand should be the default choice - but not the only choice. If your power management GUI does not provide some way of manually selecting the governor, it fails a sizeable fraction of Linux users.

(Reply to this) (Thread)

Re: Performance governor is necessary for predictability
[info]mjg59
2008-11-24 12:23 am UTC (link)
The issue is that it will give you predictable performance

No it won't. It'll give you more predictable performance, but Linux isn't a realtime operating system. If your code assumes predictability, it's already broken. Stop doing that.

(Reply to this) (Parent)(Thread)

Re: Performance governor is necessary for predictability - (Anonymous), 2008-11-24 01:35 am UTC
Re: Performance governor is necessary for predictability - [info]mjg59, 2008-11-24 01:47 am UTC
Re: Performance governor is necessary for predictability - [info]mjg59, 2008-11-24 12:32 am UTC
Re: Performance governor is necessary for predictability - (Anonymous), 2008-11-24 01:38 am UTC
Re: Performance governor is necessary for predictability - [info]mjg59, 2008-11-24 01:45 am UTC
Re: Performance governor is necessary for predictability - (Anonymous), 2008-11-24 03:16 am UTC
Re: Performance governor is necessary for predictability - [info]lionsphil, 2008-11-24 11:51 am UTC

(Anonymous)
2008-11-24 09:22 pm UTC (link)
To a first approximation, the Powersave governor will only save you power if you're playing 3D games


And only badly written 3D games at that. If a 3D game does the smart thing, namely limiting its frame rate to some reasonable value (60fps for instance) and sleeping when it doesn't have anything to do, it should work best with ondemand. powersave only seems likely to help with games that draw as many frames per second as they can.

(Reply to this)


(72 comments) - (Post a new comment)

Create an Account
Forgot your login or password?
Login w/ OpenID
English • Español • Deutsch • Русский…