Re: Attempted summary of suspend-blockers LKML thread

[Paul E. McKenney]

On Fri, Aug 06, 2010 at 01:29:57AM -0700, david@xxxxxxx wrote:
> On Thu, 5 Aug 2010, Paul E. McKenney wrote:
> 
> >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.  ;-)
> 
> hmm, I've been thinking and talking in terms of two classes of
> cgroups, trusted and untrusted. I wonder if it would be possible to
> set timeouts for each cgroup instead)
> 
> the system would go to sleep IFF all cgroups have been idle longer
> than the idle time (with -1 idle time being 'ignore this cgroup')
> 
> if this could be done you could set longer times for things designed
> for user-interaction than you do for other purposes.
> 
> you could set media to 0 idle time (so that as soon as it finishes
> processing the system can sleep until the next timer)
> 
> to do this, the code making the decision would have to be able to
> find out the following fairly cheaply.
> 
> 1. for this cgroup, what was the last time something ran
> 
> 2. for this cgroup, what is the next timer set
> 
> it would be nice to get network traffic/connection stats.
> 
> so two questions.
> 
> first, what else would you need to get accumulated for the cgroup
> 
> second, is there a fairly easy way to have these stats available?
> 
> for the 'last time it ran' stat, this seems like you could have a
> per-cpu variable per cgroup that's fairly cheap to update, but you
> would need to take a global lock to read accuratly (the lock may be
> expensive enough that it's worth trying to read the variables from
> the other cpu without a lock, just to see if it's remotely possible
> to sleep/suspend)
> 
> with timers, is it possible to have multiple timer wheels (one per
> cgroup)?

I apologize in advance for what I am about to write, but...

If you continue in this vein, you are likely to make suspend blockers
look very simple and natural.  ;-)

							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/