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

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

On Fri, May 28, 2010 at 01:21:38PM +0100, Alan Cox wrote:

> So I put my phone down
> 
> 	The UI manager gets told the phone is 'down'
> 	Ten seconds later it is still down
            <- wakeup event that should be delivered to untrusted app arrives here

At this point you may mark the downtrodden group as ignored between the 
untrusted app receiving the event and the untrusted app marking itself 
as important. To avoid this you need the UI manager to receive every 
wakeup event in order to change its scheduling decisions.

> If I push the button we get an IRQ
> We come out of power save
> The app gets poked

(The cgroup has to have some awareness of suspend/resume so that it can 
allow the untrusted apps to be scheduled again)

> The app may be unimportant but the IRQ means we have a new timeout of
>     some form to run down to idle

The timeout-based nature means that if the application doesn't get 
scheduled for some reason (say there's heavy swap pressure - not likely 
in the embedded world, but an issue on laptop-type devices) the event 
may not be handled before you get back to sleep. I accept that this 
isn't likely to be a problem in the real world, but it does make this 
mechanism less deterministic than a suspend block based one.

> If you are absolutely utterly paranoid about it you need the button
> driver to mark the task it wakes back as important rather than rely on
> time for response like everyone else. That specific bit is uggglly but
> worst case its just a google private patch to a few drivers. I understand
> why Android wants it. The narrower the gap between 'we are doing nothing,
> sit in lowest CPU on state' and 'we are off' the better the battery life
> and the more hittable the condition.

Not just the button driver. Every driver that generates wakeupa. This 
gets difficult when it comes to the network layer, for instance, when 
the network driver has very little idea how the packet it just received 
will be routed.

> Apart from that optional paranoia case my kernel now contains some
> trivial changes of generic value that have nothing to do with suspend
> blocking. Android has suspend blocking by choosing to use the generic
> features in its own specific way and we need almost no code writing ?

The problem is that you still have a race, and fixing that race requires 
every event that could generate a wakeup to be proxied out to the policy 
manager as well. That's a moderate additional overhead.

-- 
Matthew Garrett | mjg59@srcf.ucam.org