lkml.org 
[lkml]   [2010]   [Aug]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Attempted summary of suspend-blockers LKML thread
    On Thu, Aug 05, 2010 at 01:26:18PM -0700, david@lang.hm wrote:
    > On Thu, 5 Aug 2010, kevin granade wrote:
    >
    > >On Thu, Aug 5, 2010 at 10:46 AM, <david@lang.hm> wrote:
    > >>On Thu, 5 Aug 2010, Paul E. McKenney wrote:
    > >>
    > >>>On Wed, Aug 04, 2010 at 10:18:40PM -0700, david@lang.hm wrote:
    > >>>>
    > >>>>On Wed, 4 Aug 2010, Paul E. McKenney wrote:
    > >>>>>
    > >>>>>On Wed, Aug 04, 2010 at 05:25:53PM -0700, david@lang.hm 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


    \
     
     \ /
      Last update: 2010-08-06 01:21    [W:4.058 / U:0.112 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site