Message-ID: <alpine.DEB.2.00.1008071403000.30564@asgard.lang.hm>
Date:	Sat, 7 Aug 2010 14:20:02 -0700 (PDT)
From:	david@...g.hm
To:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
cc:	"Ted Ts'o" <tytso@....edu>, Brian Swetland <swetland@...gle.com>,
	linux-pm@...ts.linux-foundation.org, linux-kernel@...r.kernel.org,
	arve@...roid.com, mjg59@...f.ucam.org, pavel@....cz,
	florian@...kler.org, rjw@...k.pl, stern@...land.harvard.edu,
	peterz@...radead.org, tglx@...utronix.de, alan@...rguk.ukuu.org.uk,
	menage@...gle.com, david-b@...bell.net, James.Bottomley@...e.de,
	arjan@...radead.org, swmike@....pp.se, galibert@...ox.com,
	dipankar@...ibm.com
Subject: Re: Attempted summary of suspend-blockers LKML thread, take three

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

> On Sat, Aug 07, 2010 at 02:38:35AM -0700, david@...g.hm wrote:
>> On Sat, 7 Aug 2010, Ted Ts'o wrote:
>>
>>> On Fri, Aug 06, 2010 at 08:14:09PM -0700, david@...g.hm 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists