We all know controlling latency is the best way to control power consumption and still have a usable system. Putting the processor into deeper sleep states saves power, but it takes longer to come back to running. On pretty much all devices it’s all a trade off between time and power.
org.freedesktop.DeviceKit.Power.Latency is a DBus interface implemented by DeviceKit-power. It allows applications to request target latencies, for example a couple of seconds CPU-DMA latency for an IM application, or a few hundred microseconds of network latency for a multiplayer game. The lowest value of each latency type is used for the userspace->kernel interface, and then what do do is left for the kernel drivers themselves.
Use cases:
- I want my IM application to request 0.5s latency for messages
- I’m running an OpenGL simulation and want maximum performance, even on battery
- I’m running an SQL server for a credit card company, and want the server to request low latency CPU and network as any delay costs money
- I’m an admin, and want to change the power consumption vs. latency from cron scripts so it uses high latency during the night for maximum power saving, and low latency during business hours.
- I want high throughput when copying files, but want low throughput for downloading updates in the background.
- I want my power manager to set all latencies to lowest when on AC power
- I don’t want my users messing with latency settings
- I’m and admin and I want to be able to override all latency settings on my machines
Now, I want to build a system-activated service to manage this, so people that don’t care don’t have an extra process running. We can use PolicyKit to control all the authentication, and build up a service for applications and admins to use. This will be suitable for system services and desktop applications.
Why don’t applications use the PMQoS interface directly? Well, by providing a framework we can override requests by admin policy, and also control requests. You also can’t set latencies unless you’re the root user, which is not suitable for the desktop use case.
I’ve put an interface file up here.
Comments? Suggestions? Thanks.
Something similar is required to tell the wireless hardware how deep it can go into powersaving and how much networking latency you expect: if you’re connected to an AP, that AP may buffer frames for you, and you can ask for them to be sent to you only after some time and shut down your radio in the meantime.
Therefore, it would be useful to extend such a mechanism in some way to incorporate wireless network latency/performance. Thoughts? We (the wireless kernel developers) haven’t really figured this out yet either, but obviously are willing to listen to input on how you and others would want to handle this in userspace.
sounds nice to improve battery life in various ways easily.
(what has the icon to do with power? ;) why not use a battery and a plug together or something similar?)
@Johannes:
Yes, this is exactly what PMQoS tries to do. If you watch the presentation here: http://free-electrons.com/pub/video/2008/elc/elc2008-mark-gross-power-management.ogg you can see that network latency is used in the iwl3945 driver like you suggest. The only thing that’s not been considered is multiple NICs, but I don’t see that as a primary use case or immediate problem right now.
@baze: I was trying to find an icon that looked like “latency” :-)
If this project is a good idea (after I’ve processed feedback) I’ll ask one of the icon designers to do me a logo. I don’t want to write all the code and get flashy graphics and then find nobody wants to use it…
Can someone please explain how all these DeviceKit-* implementations differ from HAL, why it is better, etc?
A birds eye view kind of thing
@hugsie:
Oh, so it’s just a typical case of Intel wireless not working with the community, as always. Why am I not surprised?
On the other hand, there’s no such code in the kernel now either, so that must be somebody’s experimental code they never bothered to show on the linux wireless list. Not really surprising of Intel wireless either though.
@John:
Funny you say that actually, David Zeuthen is writing a long blog post about DeviceKit before the weekend. I can summarise in saying that HAL has evolved from something small and self contained into a mololithic blob, doing all sorts of odd things in very legacy ways. Rewriting these into DeviceKit (core device functionality, thin smear over udev), DeviceKit-disks (lots of disk functionality, much better UI experience for formatting and partitioning) and DeviceKit-power (power management and latency) allows us to create small self contained programs that do a few things very well, also having a stable API like HAL.
Long term (5 years?), HAL is dead. In the short term, I don’t think it’s going anyware, but they’ll be no new features, and we’ll start to move functionality from HAL to smaller self contained projects. Ohh, and doing the rewrite allows us to move some stuff down to udev, some to the kernel, and share a whole lot more code with other platforms. Ohh, and DeviceKit is a whole lot quicker that HAL to startup, and because the daemons are system activated, they don’t use resources when they are not being used.
@Johannes:
Perhaps. Not sure, as I don’t get that involved, sorry. I assumed it was upstream — if you watch the video the details were presented (with code…) so I assumed it was committed. Apologies if this is not true, and I caused offence.
@hughsie:
First, apologies for missing that h!
Can’t say I’m offended, in particular not by you (!), I’m just somewhat disappointed that we discussed the wireless power management aspect at OLS and nobody there was aware of pm-qos, not even the Intel folks who work on wireless. It seems like at least some of the pm-qos design was done without asking the users, which isn’t always the best idea…
if I understand it correctly: the latency control thing is used to give the kernel some information about how much time it can let devices sleep? What’s the difference with a system that not this latency control thing?
Uhm, not sure we should be using your blog as a mailing list – any chance you can post this to devkit-devel; I have a few comments. Thanks!
http://lists.freedesktop.org/mailman/listinfo/devkit-devel
Hum.. I see that a bunch of use cases are about running some kind of server (sql server, cron scripts). Isn’t power latency control a bit overengineering in these cases, as how many serious admins are running desktop environment on a business-critical server machine?
I’m not sure how this is all supposed to work. I hope this is not yet another daemon to run? I read on Planet GNOME work is being done to improve GNOME’s start up time. Then it would be a shame that new bloat is added again. That would be two steps forward and one backward.
@Priit:
I don’t think it’s over engineering, I think it’s required for todays latency critical server workload, and the modern desktop. You don’t need to do it, but if you don’t have something like this you can’t turn on powersaving modes by default without the system running like molasses.
@Frederik:
No, the daemon is system activated, so if you’re not using it, it never gets launched.
Not everything you’ll want to do in order to conserve power when on battery has to do with latency. For example:
– shutting down unused radios such as bluetooth or wlan
– lowering display panel brightness
– shortening time required for display panel to shut down
– enabling automatic suspend-to-ram when inactive
– avoiding running non-essential background tasks such as updatedb
Do you plan for your system service to handle such things, or should that be left to something else, like for instance PPM?
@Tore:
Sure, not everything is latency related, some will be user preferences once again. I don’t want DeviceKit-power to be a policy agent like PPM or OHM, that is better left to the session in the laptop / desktop use case.