On Thu, 27 May 2010, Matthew Garrett wrote: > On Thu, May 27, 2010 at 07:52:59PM +0200, Peter Zijlstra wrote: > > > Shall we henceforth stop confusing forced suspend for laptops and > > powersaving a running system? > > If you want to support forced suspend for laptops and you want to avoid > the risk of losing wakeups then you need in-kernel suspend blockers. > That's entirely orthogonal to Android's runtime power management. Rather than continue going around in circles, let's agree that what the Android people want is a new version of forced suspend -- not a power-saving idle mode. As such, latency is simply not relevant. Here's an idea for a new approach that avoids the need for in-kernel suspend blockers. I don't know exactly how or if it can be made to work, but at least it's a different way of looking at the problem. A normal forced suspend is unconditional: It stops the system no matter what is happening. The Android people want to make it conditional: Don't stop the system until nothing "important" is happening. So what is "important"? A possible definition could go like this. Let's add a per-process (or per-thread) flag to mark "important" processes. And let's say that a process with this flag set is doing "important" work unless it is blocked inside a poll() system call. Given that definition, an opportunistic suspend is a forced suspend that waits until no important processes are doing important work (i.e., all important processes are stuck inside poll). Is this adequate to meet Android's needs? I don't know. It can handle the case of a program waiting for a keystroke or network packet to arrive. Does it allow for sufficient accounting statistics and debugging capability? I don't know -- no doubt this depends on how it is implemented. Can it be made to work? I don't know -- in fact, I don't even know how the poll() system call works internally. Certainly there is one complication that needs to be handled: While a suspend is underway, the important processes will be frozen and hence not sitting inside the poll() call. If an event occurs that normally would cause the poll to complete, we would need to make it abort the suspend. But it's difficult to detect when this happens. It may be necessary to _avoid_ freezing the important processes in order for this to work. The advantages: No more suspend blockers cluttering up random drivers all over the kernel. All the work is centralized in the poll() routines and the PM core. It is driven by userspace policy (which processes to mark as "important") rather than kernel choice. Is this doable? Is it worth doing? Is it better than using suspend blockers? Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
