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

[david]

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  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/