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@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
