So Matthew Garrett
dissects what he thinks powerdevil is doing wrong and gives a couple of point that
in his view, power managemers on the Free Desktop aren’t doing right at the moment.
Let’s have a look at Matthew’s points (I’m paraphrasing here for ease to follow,
hoping I’m not getting his points wrong):
-
“Powersave is the wrong governor”. First of all, Matthew assumes that the setting “powersave” will actually use the powersave cpufreq governor. Fair enough, the label offers it as powersaving mode. The CPU governor in use though is not the powersave governor, but the “conservative” governor, which indeed is an “ondemand” governor, meaning it gives you the extra needed CPU power when you ask for it. As its name says, it’s slightly more conservative than the ondemand governor when scaling up. Matthew gets this wrong, but he’s probably misled by the label we present to the user.
The “powersave” performance profile does more than just switching the cpufreq governor, it can also control your display’s power consumption (and in the future probably even disable animations all over the place so you don’t loose any of these CPU cycles for eye-candy). - “Thermal management is not the job of a power manager”. True, mostly. Usually, it should be controlled by the BIOS. The default setting though is usually very conservative / safe. In general, we don’t want users to fiddle with the limits (at what temperature should your CPU cooler start spinning?). Powerdevil doesn’t offer such option, so Matthew will be happy about this item. (I don’t see how Matthew gets to think that powerdevil does poke into thermal management settings, so I guess Matthews point was more a general one in the first place.)
- “Presentation mode”. Something the app does indeed. We’ve discussed this on the hardware-devel list and came to the same conclusion. Again, powerdevil doesn’t offer an option for presentation mode to the user because it’s “an application behaviour policy” as Matthew tells us. I do agree. What Matthew is missing here is that PowerDevil manages those policies. It’s in fact the central place to do so in KDE 4.2. Apps will tell powerdevil that a presentation is running, powerdevil will keep track of all apps inhibiting certain PM features (screensaver, dimming, suspend, …), check other policies (e.g. “lock screen on resume?”). There’s no “inhibit suspend” button in Powerdevil though. Downside is that we have to rely on apps actually setting this cookie — which might or might not be more reliable than the user herself. So it might take some time until this feature in powermanagement on the Free Desktop works for everybody. (Until that time, you can switch to a power profile that doesn’t suspend / screensave in the first place. All happy. :)
- “3d takes more energy than 2d”. Might be true. From my measurements, however, facts are: a) KWin with compositing enabled does hardly spend “a significant proportion of the time on the GPU”. (In fact, it sleeps most of the time.) and b) KWin in compositing mode does hardly need any more energy than when compositing is off. (Again, results of my measurements, those might be off. I’d invite Matthew or everybody else to provide additional data points so we can improve our default setting to optimize its behaviour further.) Users can of course easily check this themselves. Run powertop with compositing on, measure your CPU consumption, switch it off (alt+shift+f12), measure again, compare. In my tests, results have been in the 1% – ‘hardly measurable’ range. If that’s different on your machine, configure powerdevil to automatically switch off compositing. If you’re findings vary from mine, let me know and we can further improve powerdevil’s set of policies.
Lesson learned: Check your facts before you publically dissect the inner workings of something that is as complex as powermanagement for a desktop system and that you’re obviously not familiar enough with to judge whether this piece of software gets it right or not. I’m assuming that Matthew does know *his* stuff (his general points are pretty much all sensible). Unfortunately his arguments in the light of powerdevil’s actual implementation are all strawmen. I’d have expected a more thorough analysis from Matthew.
I’d also like to thank Matthew for his input on these matters, and I’m glad it’s not as disheartening or dramatic as he tries to put it. In fact, reading his blog, I’m now even more confident that we have something that is both, in its default setting a very sensible system to manage power consumption while not getting in the way of the user, and also very powerful for all those cases where machines are just a bit different — so we’re also set to deal with a great variety of systems and usecases.