User: Password:
Subscribe / Log in / New account

Runtime power management

Did you know...? is a subscriber-supported publication; we rely on subscribers to keep the entire operation going. Please help out by buying a subscription and keeping LWN on the net.

By Jonathan Corbet
June 10, 2009
For most general-purpose Linux deployments, power management really only comes into play at suspend and resume time. Embedded systems tend to have dedicated code which keeps the device's power usage to a minimum, but there's no real equivalent for Linux as obtained via a standard distribution installation. A new patch from Rafael Wysocki may change that situation, though, and, in the process, yield lower power usage and more reliable power management on general-purpose machines.

Rafael's patch adds infrastructure supporting a seemingly uncontroversial goal: let the kernel power down devices which are not currently being used. To that end, struct dev_pm_ops gains two new function pointers:

    int (*autosuspend)(struct device *dev);
    int (*autoresume)(struct device *dev);

The idea is simple: if the kernel decides that a specific device is not in use, and that it can be safely powered down, the autosuspend() function will be called. At some future point, autoresume() is called to bring the device back up to full functionality. The driver should, of course, take steps to save any necessary device state while the device is sleeping.

The value in this infrastructure should be reasonably clear. If the kernel can decide that system operation will not suffer if a given device is powered down, it can call the relevant autosuspend() function and save some power. But there's more to it than that; a kernel which uses this infrastructure will exercise the suspend/resume functionality in specific drivers in a regular way. That, in turn, should turn up obscure suspend/resume bugs in ways which make them relatively easy to identify and, hopefully fix. If something goes wrong when suspending or resuming a system as a whole, determining the culprit can be hard to do. If suspending a single idle device creates trouble, the source of the problem will be rather more obvious. So this infrastructure should lead to more reliable power management in general, which is a good thing.

A reading of the patch shows that one thing is missing: the code which decides when to suspend and resume specific devices. Rafael left that part as an exercise for the reader. As it turns out, different readers had rather different ideas of how this decision needs to be made.

Matthew Garrett quickly suggested that there would need to be a mechanism by which user space could set the policy to be used when deciding whether to suspend a specific device. In his view, it is simply not possible for the kernel to know, on its own, that suspending a specific device is safe. One example he gives is eSATA; an eSATA interface is not distinguishable (by the kernel) from an ordinary SATA interface, but it supports hotplugging of disks. If the kernel suspends an "unused" eSATA controller, it will fail to notice when the user attaches a new device. Another example is keyboards; it may make sense to suspend a keyboard while the screen saver is running - unless the user is running an audio player and expects the volume keys to work. Situations like this are hard for the kernel to figure out.

Ingo Molnar has taken a different approach, arguing that this kind of decision really belongs in the kernel. The kernel should, he says, suspend devices by default whenever it is safe to do so; there's no point in asking user space first.

Again, the user wont enter anything, in 95% of the cases - in the remaining 3% of cases what is entered is wrong and only in another 2% of cases is it correct ;-)

Sane kernel defaults are important and the kernel sure knows what kind of hardware it runs on. This 'let the user decide policy' for something as fundamental (and also as arcane) as power saving mode is really a disease that has caused a lot of unnecessary pain in Linux in the past 15 years.

The discussion went back and forth without much in the way of seeming agreement. But the difference between the two positions is, perhaps, not as large as it seems. Ingo argues for automatically suspending devices where this operation is known to be safe, and he acknowledges that this may not be true for the majority of devices out there. That is not too far from Matthew's position that a variety of devices cannot be automatically suspended in a safe way. But, Ingo says, we should go ahead and apply automatic power management in the cases where we know it can be done, and we should expect that the number of devices with sophisticated (and correct) power management functionality will grow over time.

So the only real disagreement is over how the kernel can know whether a given device can be suspended or not. Ingo would like to see the kernel figure it out from the information which is already available; Matthew thinks that some sort of new policy-setting interface will be required. Answering that question may not be possible until somebody has tried to implement a fully in-kernel policy, and that may take a while. In the mean time, though, at least we will have the infrastructure which lets developers begin to play with potential solutions.

(Log in to post comments)

Runtime power management

Posted Jun 11, 2009 2:59 UTC (Thu) by ncm (subscriber, #165) [Link]

When people as smart as Ingo and Matthew disagree, I'm inclined to give up completely. However, I wonder if the driver can't itself tell the kernel, at load time, to call autosuspend at its discretion. Certainly my sound chip's driver knows that turning it off is always safe.

Runtime power management

Posted Jun 11, 2009 3:44 UTC (Thu) by mjg59 (subscriber, #23239) [Link]

Sound's a nice easy one - powering down the codec doesn't cost you any functionality. It can be powered back up the moment you open it and you still get jack autosensing. The problem arises when powering down a component costs you something, such as hotplug support. Many users won't care, but some users will. We can't know the user's requirements without them feeding them to us somehow.

I'm absolutely in favour of pushing a more thorough autosuspend framework into Linux and I'm thrilled by Rafael's work here. My only concern is ensuring that we have a method by which userspace can impose its own policy on the kernel's default policy. That might take the form of disabling autosuspend entirely (when the user needs that functionality) or it might take the form of tweaking options - for instance, an active user is likely to favour some amount of reduced latency at the cost of increased power draw when it comes to hard drive spindown. Once the screensaver has activated that tradeoff can be altered. This is the kind of heuristic we can generate based on pulling information from multiple sources, and while we could implement that in the kernel I expect that it would end up being ridiculously awkward.

Runtime power management

Posted Jun 11, 2009 8:12 UTC (Thu) by ncm (subscriber, #165) [Link]

Thanks, Matthew. I guess many devices should be suspended much of the time even if some process has them open, or even mounted, and others have to be polled periodically and then turned off immediately if there's nothing to do. Does this mean another enormous table of devices (e.g. everything that might show up in a USB socket) in /etc with a policy for each? Is udev the right place for that?

Runtime power management

Posted Jun 11, 2009 11:36 UTC (Thu) by MathFox (guest, #6104) [Link]

I agree that the autosuspend framework is interesting work. I have a few questions about the proposed interface: Might there be a use case where the suspend/resume code could need device-specific information? Would such information require an additional change to the device interface or are there existing calls that can provide the desired information?

Runtime power management

Posted Jun 12, 2009 10:50 UTC (Fri) by ranmachan (subscriber, #21283) [Link]

> The problem arises when powering down a component costs you something, such as hotplug support.

I think that's easily solvable in the driver.
The driver should know it's a hotplug capable and it could just wake up the device every once in a while to check if the user plugged something in in the meantime. I think maybe a 1 to at most 5 second delay between plugging in an eSATA disk and the kernel detecting it would be acceptable IMHO.

Runtime power management

Posted Jun 11, 2009 18:42 UTC (Thu) by roy23 (subscriber, #3926) [Link]

I'd like my video card to be powered down except when I am looking at the monitor :)

But in all seriousness, my server/pvr is 97% doing nothing, 2% recording a tv program, 1% watching a recording (yup, I am in ever-increasing backlog). The video chip is only used 1% of the time.

Runtime power management

Posted Jun 12, 2009 6:42 UTC (Fri) by jzbiciak (subscriber, #5246) [Link]

I know you were speaking tongue-in-cheek, but if the graphics acceleration is in a different power domain from the frame-buffer raster scanner, then that can be powered down. Likewise, if there's a video decoder core, that too can be powered down.

That's how all those SoCs like OMAP work that go in cell phones and other gadgets. They'll leave the LCD interface up when the display is on so the LCD refreshes, but only power up the graphics and video accelerators when they're needed.

Killing keyboard on screen saver

Posted Jun 12, 2009 10:22 UTC (Fri) by zdzichu (subscriber, #17118) [Link]

While I agree that running screensaver is a strong hint for turning off devices, I disagree with example given. How I am supposed to deactivate screensaver with disabled keyboard?

Killing keyboard on screen saver

Posted Jun 12, 2009 11:04 UTC (Fri) by mjg59 (subscriber, #23239) [Link]

Remote wakeup allows the keyboard to power back up when a key is hit. The OS knows that the keyboard has been powered back up, but not which key was pressed.

Copyright © 2009, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds