Re: Attempted summary of suspend-blockers LKML thread

[Paul E. McKenney]

On Thu, Aug 05, 2010 at 01:26:18PM -0700, david@xxxxxxx wrote:
> On Thu, 5 Aug 2010, kevin granade wrote:
> 
> >On Thu, Aug 5, 2010 at 10:46 AM,  <david@xxxxxxx> wrote:
> >>On Thu, 5 Aug 2010, Paul E. McKenney wrote:
> >>
> >>>On Wed, Aug 04, 2010 at 10:18:40PM -0700, david@xxxxxxx wrote:
> >>>>
> >>>>On Wed, 4 Aug 2010, Paul E. McKenney wrote:
> >>>>>
> >>>>>On Wed, Aug 04, 2010 at 05:25:53PM -0700, david@xxxxxxx wrote:
> >>>>>>
> >>>>>>On Wed, 4 Aug 2010, Paul E. McKenney wrote:
> >>>
> >>>[ . . . ]
> >>>
> >>however, in the case of Android I think the timeouts have to end up being
> >>_much_ longer. Otherwise you have the problem of loading an untrusted book
> >>reader app on the device and the device suspends while you are reading the
> >>page.
> >>
> >>currently Android works around this by having a wakelock held whenever the
> >>display is on. This seems backwards to me, the display should be on because
> >>the system is not suspended, not the system is prevented from suspending
> >>because the display is on.
> >>
> >>Rather than having the display be on causing a wavelock to be held (with the
> >>code that is controls the display having a timeout for how long it leaves
> >>the display on), I would invert this and have the timeout be based on system
> >>activity, and when it decides the system is not active, turn off the display
> >>(along with other things as it suspends)
> >
> >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.
> >
> >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
> 
> when you suspend the audio will shut off, so it's sleep ->wake ->
> sleep, not 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.
> 
> it really depnds on the frequency of the wakeups.
> 
> if you get a network packet once every 5 min and need to wake to
> process it, staying awake for 20 seconds after finishing procesing
> is FAR more significant than if you get a network packet once every
> hour. It's not just the factor of 20 that simple math would indicate
> because the time in suspend eats power as well.
> 
> I don't know real numbers, so these are made up for this example
> 
> if suspend (with the cell live to receive packets) is 10ma average
> current and full power is 500ma average current
> 
> packets every 5 min with .1 sec wake time will eat ~13maH per hour
> 
> packets every 5 min with 10 second wake time will eat ~37maH per hour
> 
> packets every hour with .1 sec wake time will eat ~10maH per hour
> 
> packets every hour with 10 sec wake time will eat ~11maH per hour
> 
> so if you have frequent wakeups, staying awake 100 times as long
> will cut your battery life to 1/3 what it was before.
> 
> if your wakeups are rare, it's about a 10% hit to stay awake 100
> times as long.
> 
> there is a lot of room for tuning the timeouts here.

Especially given different scenarios, for example, audio playback
when the device is in airplane mode.  ;-)

							Thanx, Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/