Re: Attempted summary of suspend-blockers LKML thread, take three

From: david
Date: Sat Aug 07 2010 - 17:22:25 EST

On Sat, 7 Aug 2010, Paul E. McKenney wrote:

On Sat, Aug 07, 2010 at 02:38:35AM -0700, david@xxxxxxx wrote:
On Sat, 7 Aug 2010, Ted Ts'o wrote:

On Fri, Aug 06, 2010 at 08:14:09PM -0700, david@xxxxxxx wrote:

So the real key here is to take most applications, which may be
written using techniques that might be considered well written from a
laptop point of view, but not for a cell phone, and not require
modifications. Even though the application writer might think it's
doing well by waking up every 15 seconds, if the laptop lid is down,
or if the screen is off, for **most** applications, it should be
forcibly put to sleep.

It's only the rare applications that should really be allowed to run
while screen is off. And it's only those applications that need
modifications to use suspend blocker. From your earlier comments, it
seems that this is the key point which you are missing. (No doubt,
some of these applications that do need to know about suspend blockers
are important ones; ones that make sure the battery isn't about to
blow up, or ones which silently wake up every 10-15 minutes to pull
down fresh mail for you from your mail server. But those applications
are the exception, not the rule.)

the question is what it takes to make an application privilaged like this.

what I proposed was to make it possible for the user/admin to select
what applications are allowed to keep the system awake.

The Android guys do the same.

wakelocks require that the application developer decide that they
want to keep the system awake as well as the user/admin

Whereas you require that the application developer redesign/rewrite
applications to decide when to keep the system awake, e.g., by carefully
determining when to idle themselves. The difference is that the Android
developer need only release a suspend blocker. In contrast, you are
requiring that the developer rewrite all the code that follows the point
where the Android developer would release a suspend blocker.

Your way seems to require that the developer do more work for the
same result. Why?

portability, and the fact that it will save more power even when the system is prevented from suspending.

take your example of a mail client waking up every 15 min.

with Android it needs to be privilaged to grab the wakelock while
fetching the mail, it also needs to use a privilaged API to set the
wakeups to wake it up at those times.

with what I proposed all you need to do is to tag the application as
power privilaged and then if the application sleeps for 15 min
between doing thing the system will wake up every 15 min, work for a
short time, then go back to sleep.

if you want to put everything to sleep when the screen blanks,
that's trivial to do.

the fun starts when you want to say that there are some things you
don't want to put to sleep.

Which is in fact a critical requirement that you appear to have been
ignoring in your words above.

I admit that the way I wrote this is confusing, but I don't think I am ignoring this requirement. the example above was how an application that the system is not wanting to put to sleep would run with the two mechansims.

do you let some processes run while halting others?
in which case how do you prevent deadlocks?
on the other hand, sleeping again is simple, you sleep when
there is nothing more to run
or do you let wasteful processes run while you are awake?
this avoids deadlocks, but how do you decide when to sleep again?

Android approaches this by requiring that any program that a user
may want to keep running must be modified to use wakelocks.

My suggestion was that the system ignore other processes when
deciding if the system is idle enough to put to sleep.

But your suggestion seems to require quite a bit more coding effort for
little gain. The Android developer can just release a suspend blocker,
and in contrast, a developer using your proposal needs to rewrite all
the code following the point at which the Android developer released the
suspend blocker. So why are you saying that your is approach better? ;-)

no, the coder needs to make his code not do unnessasary things. Even with a wakelock this is needed for the system to be able to use lower power modes while the system is not going to do a suspend anyway.

I am say that if the coder does that, the coder should not also have to code in wakelocks.

I want it to be as easy as possible to port applications between mobile platforms. On most platforms wakelocks are not needed because standard idle/sleep/suspend mechanisms are good enough. Android allows other applications to run that confuse the idle/sleep/suspend mechanisms, so something needs to be done to cut through the confusion. Android does this by creating a new API to control this, I'm suggesting that there should be a way to tell the system to ignore the other applications so that the existing mechanisms can make good decisions again.

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