Message-ID: <alpine.DEB.2.00.1008101821280.23481@asgard.lang.hm>
Date:	Tue, 10 Aug 2010 18:28:39 -0700 (PDT)
From:	david@...g.hm
To:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
cc:	Alan Cox <alan@...rguk.ukuu.org.uk>, "Ted Ts'o" <tytso@....edu>,
	Felipe Contreras <felipe.contreras@...il.com>,
	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, 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 Tue, 10 Aug 2010, Paul E. McKenney wrote:

> On Tue, Aug 10, 2010 at 09:38:49AM +0100, Alan Cox wrote:
>>> situation you call out can occur with manual suspend-to-RAM already:
>>> the fact is that this is a design choice.  You could indeed make a
>>
>> Losing data is a design choice ? The application set a timer, the OS
>> shouldn't be ignoring it in that situation. It might want to delay it, it
>> might want to warn the user its hogging things it shouldnt (powertop,
>> battery usage monitors in Android etc)
>
> Hmmm...  Let's put the two approaches side by side so that we can compare
> them more easily:
>
> 	Opportunistic Suspend		Idle + Timer Jitter
>
> 	Set timer			Set timer
> 	Suspend				OS delays timer
> 	Resume				OS continues delaying timer
> 	Timer fires			Timer fires
>
> These two cases look quite similar to me.
>
> But as you say, the battery can run out.  So let's add that to the
> comparison:
>
> 	Opportunistic Suspend		Idle + Timer Jitter
>
> 	Set timer			Set timer
> 	Suspend				OS delays timer
> 	Battery runs out		Battery runs out
> 	Data loss			Data loss
>
> The two cases still look quite similar.  You might note, quite correctly,
> that the time between suspend and resume might be quite a bit longer than
> the typical time that the OS delays a timer.  But the power consumption
> on some platforms is quite a bit lower in the suspend case than it is
> in the delayed-timer case.

it has been stated that the android can hit the exact same power state 
either with sleep or suspend, and that the same clock can wake it up 
(it appears as a timer expiring for sleep, or an alarm for suspend, but 
it's the same clock firing the signal)

so in at least some cases the hardware supports doing both with equal 
efficiency.

>>> But that doesn't guarantee that solutions developed for PCs and laptops
>>> will be optimal (or even usable) on cellphones.  Sufficient difference
>>
>> Your cellphone is to all intents a laptop from ten years ago, it even has
>> a similar display resolution and internet availability. The underlying
>> difference between the two is solely form factor - the laptop had a
>> better keyboard.
>
> There are similarities and differences.  You have called out some of
> the similarities.  Differences include the more-aggressive hardware
> power management on cellphones, the greater number and variety of
> hardware accelerators on cellphones, battery capacity, and, as you say,
> physical size.  People currently use cellphones differently than they
> do laptops or desktops.  The usage might converge, but we will see.
> There is as much reason to expect increasing specialization as there
> is to expect increasing convergence.

You are talking about Android as if it was a cell phone only thing, it's 
not. there are shipping tablets (and I believe netbooks, i.e. laptops) 
running andoid.

>>> As to busting all apps, lthough there have been situations where busting
>>> all the apps turned out to be the right thing to do, I agree that these
>>> situations are extremely rare.  Such situations are usually associated
>>> with the emergence of a new high-volume platform.
>>
>> Like Microsoft Windows 16bit co-operative multi-tasking ? It's rarely
>> right. It's merely that in certain cases the value in the market is large
>> enough that it can be used as a big stick to beat people into doing lots
>> of usually wasted work.
>
> Interesting choice of example.  I do well remember the Sequent hardware
> guys' frustration when the old printer driver would monopolize the desktop
> while printing their large documents.  The fact was that Microsoft's
> co-operative multi-tasking required all applications to be well behaved,
> just as does your approach to power efficiency.

and wakelocks require all applications that can take a wakelock be well 
behaved. and applications that do nt take a wakelock directly cannot 
expect to run unless something else takes a wakelock on their behalf

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