Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Matthew Garrett <mjg59@srcf.ucam.org>]

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@srcf.ucam.org