On Sun, Feb 08, 2009 at 06:04:04AM -0800, Brian Swetland wrote: > Being in suspend, where periodic user and kernel timers aren't running, > and random userspace threads aren't possibly spinning, rather than just > being in idle in the lowest power possible state, represent a pretty > significant power savings. Nokia have produced a Linux-based device that runs off a phone battery and has roughly a week of standby time without entering an explicit suspend state at any time, so dealing with this is clearly possible. What we need is to ensure that driver interfaces allow the kernel to know when a given piece of hardware is required and place it in an appropriate power state - the USB autosuspend code is probably the best kernelwide example of this right now. Part of the reason you're getting pushback is that your solution to the problem of shutting down unused hardware is tied to embedded-style systems with very low resume latencies. You can afford to handle the problem by entering an explicit suspend state. In the x86 mobile world, we don't have that option. It's simply too slow and disruptive to the user experience. As a consequence we're far more interested in hardware power management that doesn't require an explicit system-wide suspend. A solution that's focused on powering down as much unused hardware as possible regardless of the system state benefits the x86 world as well as the embedded world, so I think there's a fairly strong argument that it's a better solution than one requiring an explicit system state change. Arve mentioned that your hardware enters the same power state in idle as in suspend, so the only real difference here is that in the "better" solution you're inferring that the hardware is idle based on the demands of userspace rather than explicitly shutting it down. At least, from the kernel side. The userspace side is more awkward - as Pavel suggested you could obtain a pretty similar outcome by just sending SIGSTOP to pretty much everything, which is kind of ugly but would probably work. -- Matthew Garrett | mjg59@xxxxxxxxxxxxx _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
