Message-ID: <alpine.DEB.2.00.1008101057090.23481@asgard.lang.hm>
Date:	Tue, 10 Aug 2010 11:07:20 -0700 (PDT)
From:	david@...g.hm
To:	Matthew Garrett <mjg59@...f.ucam.org>
cc:	Alan Cox <alan@...rguk.ukuu.org.uk>, paulmck@...ux.vnet.ibm.com,
	"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, 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, Matthew Garrett wrote:

> On Tue, Aug 10, 2010 at 09:38:49AM +0100, Alan Cox wrote:
>>> Hmmm...  Exactly which part do you consider flawed?  Let's take it
>>> one sentence at a time.  The devices that I know of that lack suspend
>>> blockers also lack opportunistic suspend.  Therefore, all applications on
>>> such devices run as would an application that acquired a suspend blocker
>>> when it started and did not release that suspend blocker until it exited.
>>> Pretty straightforward.
>>
>> What do you mean by "opportunistic suspend", lots of systems drop into
>> lowest power states whenever they can. "Suspend is different" is a bit of
>> Android religion that I am dubious has any basis in reality as seen from
>> the application end of the universe.
>>
>> You may also wish to review the earlier parts of the discussion where it
>> was explicitly stated by several developers that they were using
>> "suspend" type modes as power states already and not using suspend
>> blockers. So it's being done, today on ARM and your statement is directly
>> contradicting the code. Modern ARM processors and x86 MID devices can
>> suspend and resume extremely fast (fast enough that the fact Linux x86
>> rewriting all the SMP alternatives on suspend/resume is a measurable
>> problem). If this same property doesn't end up on big PC boxes in time
>> then I'd be very surprised. At that point the openoffice with suspend
>> blockers or oracle with suspend blockers question becomes rather relevant.
>
> There's a clear and absolute difference between system suspend and
> entering the same hardware state from the idle loop. That difference is
> that processes aren't scheduled until an explicit wakeup event occurs.
> Android is entirely capable of entering the same low power state at idle
> (it's done with a hardcoded idle loop on Qualcomm, cpuidle on omap), but
> if you have more than 0 scheduling wakeups a second then your power draw
> is going to be greater.
>
> I agree that we should be targetting 0 wakeups per second. I don't agree
> that it's realistic to insist that a use model that assumes imperfect
> software is an invalid use model.

If the primary difference between sleep and suspend is not scheduling 
processes, instead of messing with oppurtinistic suspend/suspend 
blockers/wakelocks/etc, why not just 'temporarily' change the timer fuzz 
value to a very large value (say an hour). That would still let things 
like openoffice saves ahve a fair chance to trigger before the battery 
died completely, but would wake the system so infrequently that it will be 
effectivly the same as a full suspend.

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