Date:	Thu, 5 Aug 2010 15:09:32 -0700 (PDT)
From:	david@...g.hm
To:	kevin granade <kevin.granade@...il.com>
cc:	paulmck@...ux.vnet.ibm.com,
	Arve Hjønnevåg <arve@...roid.com>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Arjan van de Ven <arjan@...radead.org>,
	linux-pm@...ts.linux-foundation.org, linux-kernel@...r.kernel.org,
	pavel@....cz, florian@...kler.org, stern@...land.harvard.edu,
	swetland@...gle.com, peterz@...radead.org, tglx@...utronix.de,
	alan@...rguk.ukuu.org.uk
Subject: Re: Attempted summary of suspend-blockers LKML thread

On Thu, 5 Aug 2010, kevin granade wrote:

> On Thu, Aug 5, 2010 at 3:31 PM, Paul E. McKenney
> <paulmck@...ux.vnet.ibm.com> wrote:
>> On Thu, Aug 05, 2010 at 01:13:31PM -0500, kevin granade wrote:
>>> On Thu, Aug 5, 2010 at 10:46 AM,  <david@...g.hm> wrote:
>>>> On Thu, 5 Aug 2010, Paul E. McKenney wrote:
>>>>
>>>>>
>>>>> [ . . . ]
>>>>>
>>>>>
>>>>> My (possibly incorrect) assumption is based on the complaint that led
>>>>> to my implementing RCU_FAST_NO_HZ.  A (non-Android) embedded person was
>>>>> quite annoyed (to put it mildly) at the earlier version of RCU because
>>>>> it prevented the system from entering the power-saving dyntick-idle mode,
>>>>> not for minutes, or even for seconds, but for a handful of -milliseconds-.
>>>>> This was my first hint that "energy efficiency" means something completely
>>>>> different in embedded systems than it does in the servers that I am
>>>>> used to.
>>>>>
>>>>> But I must defer to the Android guys on this -- who knows, perhaps
>>>>> multi-minute delays to enter full-suspend mode are OK for them.
>>>>
>>>> if the system was looking at all applications I would agree that the timeout
>>>> should be much shorter.
>>>>
>>>> I have a couple devices that are able to have the display usable, even if
>>>> the CPU is asleep (the OLPC and the Kindle, two different display
>>>> technologies). With these devices I would like to see the suspend happen so
>>>> fast that it can suspend between keystrokes.
>>>>
>>>> however, in the case of Android I think the timeouts have to end up being
>>>> _much_ longer. Otherwise you have the problem of loading an untrusted book
>>>> reader app on the device and the device suspends while you are reading the
>>>> page.
>>>>
>>>> currently Android works around this by having a wakelock held whenever the
>>>> display is on. This seems backwards to me, the display should be on because
>>>> the system is not suspended, not the system is prevented from suspending
>>>> because the display is on.
>>>>
>>>> Rather than having the display be on causing a wavelock to be held (with the
>>>> code that is controls the display having a timeout for how long it leaves
>>>> the display on), I would invert this and have the timeout be based on system
>>>> activity, and when it decides the system is not active, turn off the display
>>>> (along with other things as it suspends)
>>>
>>> IIRC, this was a major point of their (Android's) power management
>>> policy.  User input of any kind would reset the "display active"
>>> timeout, which is the primary thing keeping random untrusted
>>> user-facing programs from being suspended while in use.  They seemed
>>> to consider this to be a special case in their policy, but from the
>>> kernel's point of view it is just another suspend blocker being held.
>>>
>>> I'm not sure this is the best use case to look at though, because
>>> since it is user-facing, the timeout durations are on a different
>>> scale than the ones they are really worried about.  I think another
>>> category of use case that they are worried about is:
>>>
>>> (in suspend) -> wakeup due to network -> process network activity -> suspend
>>>
>>> or an example that has been mentioned previously:
>>>
>>> (in suspend) -> wakeup due to alarm for audio processing -> process
>>> batch of audio -> suspend
>>>
>>> In both of these cases, the display may never power on (phone might
>>> beep to indicate txt message or email, audio just keeps playing), so
>>> the magnitude of the "timeout" for suspending again should be very
>>> small.  Specifically, they don't want there to be a timeout at all, so
>>> as little time as possible time is spent out of suspend in addition to
>>> the time required to handle the event that caused wakeup.
>>
>> It would be good to get some sort of range for the "timeout".  In the
>> audio-output case, my understanding that the spacing between bursts of
>> audio-processing activity is measured in some hundreds of milliseconds,
>> in which case one would want the delays until suspend to be on the
>> millisecond scale.  But does Android really suspend between bursts of
>> audio processing while playing music?  Very cool if so!  ;-)
>
> Oops, yea that's actually a really bad example, that's probably
> something that would be handled by low-power states.  I think the
> incoming text message example is a good one though.  There seemed to
> be a focus on user-interaction scale time scales, and I wanted to
> point out that there are also very short duration time scales to
> consider as well.

good point, but I do think the short time scales are less common than 
people think.

I'd love to get good examples of them

on my iphone when a text message arrives the phone displays an alert for 
user-interaction times (it even lights the display to show who the message 
is from, and optionally a preview of the message)

so what would wake a phone up from suspend where the phone should go back 
to sleep in under a second?

David Lang

Powered by blists - more mailing lists