On Thu, May 27, 2010 at 05:32:56PM +0200, Thomas Gleixner wrote: > On Thu, 27 May 2010, Matthew Garrett wrote: > > Now let's try this in the Android world. The user hits a key and the > > system wakes up. The input layer takes a suspend block. The application > > now draws all the cows it wants to, takes its own suspend block and > > reads the input device. This empties the queue and the kernel-level > > suspend block is released. The application then processes the event > > before releasing the suspend block. The event has been delivered and > > handled. > > Thanks for providing this example: > > 1) It proves that suspend blockers are solely designed to encourage > people to code crap. No. Suspend blockers are designed to ensure that suspend isn't racy with respect to wakeup events. The bit that mitigates badly written applications is the bit where the scheduler doesn't run any more. If you're happy with a single badly written application being able to cripple your power management story, you don't need opportunistic suspend. But you still have complications when it comes to deciding to enter suspend at the same time as you receive a wakeup event. > And you need to do that, because the user applications suspend > blocker magic is racy as hell. To work around that you sprinkle > your suspend blocker magic all over the kernel instead of telling > people how to solve the problem correctly. What /is/ the correct way to solve this problem when entering explicit suspend states? How do you guarantee that an event has been delivered to userspace before transitioning into suspend? Now, this is a less interesting problem if you're not using opportunistic suspend, but it's still a problem. > Simply because you move the cow drawing CPU time from the point > where the device wants to go into suspend to the point where the > user hits a key again. You even delay the reaction of your app to > the user input by the time it needs to finish drawing cows. It's how application mainloops tend to work. > > You can't express that with resource limits or QoS constraints. If you > > want to deal with this kind of situation then, as far as I can tell, you > > need either suspend blockers or something so close to them that it makes > > no difference. > > Wrong. If your application is interactive then you set the QoS > requirement once to interactive and be done. > > So the correct point to make a power state decision is when the app > waits for a key press. At this point the kernel can take several > pathes: > > 1) Keep the system alive because the input device is in active > state and a key press is expected > > 2) Go into supsend because the input device is deactivated after > the screen lock kicked in. That's no good. If the input device has been deactivated, how does the wakeup event get delivered to the application? > This behaves exactly the same way in terms of power consumption as > your blocker example just without all the mess you are trying to > create. And means that wakeup events don't get delivered. That's a shortcoming. -- Matthew Garrett | mjg59@xxxxxxxxxxxxx -- 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
