Re: Attempted summary of suspend-blockers LKML thread

From: david
Date: Thu Aug 05 2010 - 09:06:43 EST

On Thu, 5 Aug 2010, Florian Mickler wrote:

On Thu, 5 Aug 2010 07:33:59 +0200
Florian Mickler <florian@xxxxxxxxxxx> wrote:

On Wed, 4 Aug 2010 16:10:03 -0700
"Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx> wrote:

No no. In the David-Lang-CGroup-Scheme[1](tm?) suspend-from-idle
is used. For idle decision a certain subset of tasks is ignored.

Where suspend is prevented by the trusted
process in android-world taking a wakelock, here it would just prevent
the system from going idle by arming timers.

This would be pretty equivalent to the suspend-blocker scheme and not
introduce new userspace api. But the downside is, as Arve pointed out,
that now one can not get full-idle-power-leverage while suspend
is blocked.

[1] and


There are a few downsides that got mentioned already in reponse.. I got
a little lagged behind.

There are upsides to this approach like not
having a special purpose userspace api, conceptually integrating
suspend into the idle mechanism ..

first off, a good summary of that I've been saying, thanks.

Short summary of the cons that got mentioned:

- applications need to resort to polling to keep the system
out of idle (-> system will never be fully idle)

true, although the power difference between a system that is completelyidle (but with a wavelock held) and a system where one application is polling every 10 seconds or so is _really_ low.

- the race between deciding to suspend and becoming active
again is not handled

this one I will admit to not fully understanding, it sounds like there are opptions here, but I don't understand them or their trade-offs

- no special statistics available

or no special statistics needed. Powertop is already avaible to analyse a system and report what processes are keeping it awake. Why would this not be enough?

- the timers of the ignored applications will behave unexpected
(as the monotonic clock is not stopped)... while applications
have already to cope with network-loss, other side effects of
suspend without monotonic clock stopped are to be expected...

I'm not sure this is true. there's nothing stopping the suspend (when it finally does happen) from stopping the monotonic clock. The core of my proposal is tweaking how we decide to suspend. Other than the possibility that we decide to suspend between timers (and set an alarm to wake up when a timer would go off) I'm not suggesting that the suspend itself change once it's finally triggered.

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