Re: Attempted summary of suspend-blockers LKML thread

From: david
Date: Thu Aug 05 2010 - 16:31:54 EST

On Thu, 5 Aug 2010, Brian Swetland wrote:

On Thu, Aug 5, 2010 at 11:13 AM, kevin granade <kevin.granade@xxxxxxxxx> wrote:
IIRC, this was a major point of their (Android's) power management
policy. ÂUser input of any kind would reset the "display active"
timeout, which is the primary thing keeping random untrusted
user-facing programs from being suspended while in use. ÂThey seemed
to consider this to be a special case in their policy, but from the
kernel's point of view it is just another suspend blocker being held.

The display being on should not prevent suspend unless the particular
platform is incapable of suspending while the display is on.

if that is the case, I'll go back to my question about the untrusted reader app.

what is it that will prevent the system from going to sleep while I am reading the page?

I'm not sure this is the best use case to look at though, because
since it is user-facing, the timeout durations are on a different
scale than the ones they are really worried about. ÂI think another
category of use case that they are worried about is:

(in suspend) -> wakeup due to network -> process network activity -> suspend

or an example that has been mentioned previously:

(in suspend) -> wakeup due to alarm for audio processing -> process
batch of audio -> suspend

In both of these cases, the display may never power on (phone might
beep to indicate txt message or email, audio just keeps playing), so
the magnitude of the "timeout" for suspending again should be very
small. ÂSpecifically, they don't want there to be a timeout at all, so
as little time as possible time is spent out of suspend in addition to
the time required to handle the event that caused wakeup.

Yeah, we much prefer the wakelock model where the moment the resource
(system-needing-to-not-be-suspended) is released we return to the
lowest power state, rather than waiting for a timer to expire (and/or
burning cycles polling for "can we suspend yet?" when we're definitely
not ready to suspend).

at the micro level it is definantly better for power, but at the macro level I don't think it needs to make much difference in the overall battery life of the device. To borrow a phrase, I think you may be into premature optimization of power :-)

David Lang