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 _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
