Re: Attempted summary of suspend-blockers LKML thread

From: david
Date: Fri Aug 06 2010 - 04:32:04 EST

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

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)?

David Lang
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at