Re: Attempted summary of suspend-blockers LKML thread

[david@lang.hm]

On Wed, 4 Aug 2010, Paul E. McKenney wrote:

> On Wed, Aug 04, 2010 at 05:25:53PM -0700, david@lang.hm wrote:
>> On Wed, 4 Aug 2010, Paul E. McKenney wrote:
>>
>>> On Wed, Aug 04, 2010 at 04:49:22PM -0700, david@lang.hm wrote:
>>>> On Wed, 4 Aug 2010, Paul E. McKenney wrote:
>>>>
>>>>> On Wed, Aug 04, 2010 at 04:23:43PM -0700, david@lang.hm wrote:
>>>>>> On Wed, 4 Aug 2010, Arve Hj?nnev?g wrote:
>>>>>>
>>>>>>>
>>>>>>> We suspend as soon as no wakelocks are held. There is no delay.
>>>>>>
>>>>>> So, if I have a bookreader app that is not allowed to get the
>>>>>> wakelock, and nothing else is running, the system will suspend
>>>>>> immediatly after I click a button to go to the next page? it will
>>>>>> not stay awake to give me a chance to read the page at all?
>>>>>>
>>>>>> how can any application run without wakelock privilages?
>>>>>
>>>>> Isn't a wakelock held as long as the display is lit, so that the
>>>>> system would continue running as long as the page was visible?
>>>>
>>>> what holds this wakelock, and what sort of timeout does it have?
>>>> (and why could that same timeout be used in other ways instead)
>>>
>>> I defer to the Android guys on what exactly holds the display's
>>> wakelock.  The timeout is the display-blank timeout.
>>>
>>>> how many apps really need to keep running after the screen blanks?
>>>> there are a few (audio output apps, including music player and
>>>> Navigation directions), but I don't have see a problem with them
>>>> being marked as the 'trusted' apps to pay attention instead.
>>>
>>> Downloading is another.
>>
>> this is definantly an interesting case, do you want an active
>> network connection to keep the machine awake? if so do you want it
>> for all network connections, or only for some...
>
> The Android approach is that everything is permitted to run when the
> device is not suspended.  So that would be all network connections.

I wasn't suggesting freezing some network connections while letting others 
run, I was thinking in terms of 'if the system patcher daemon is 
downloading, don't go to sleep, but if it's dancing cows (or mail client 
to an IMAP server) go ahead and sleep, even if there is some data passing 
over the connection.

>>> The music player is an interesting example.  It would be idle most
>>> of the time, given that audio output doesn't consume very much CPU.
>>> So you would not want to suspend the system just because there were
>>> no runnable processes.  In contrast, allowing the music player to
>>> hold a wake lock lets the system know that it would not be appropriate
>>> to suspend.
>>>
>>> Or am I misunderstanding what you are proposing?
>>
>> the system would need to be idle for 'long enough' (configurable)
>> before deciding to suspend, so as long as 'long enough' is longer
>> than the music player is idle this would not be a problem.
>
> From a user standpoint, having the music player tell the system when
> it is OK to suspend (e.g., when the user has paused playback) seems
> a lot nicer than having configurable timeouts that need tweaking.

every system that I have seen has a configurable "sleep if it's idle for 
this long" knob. On the iphone (work issue, I didn't want it) that I am 
currently using it can be configured from 1 min to 5 min.

this is the sort of timeout I am talking about.

with something in the multi-minute range for the 'do a full suspend' doing 
a wakeup every few 10s of seconds is perfectly safe.

>>>> if the backlight being on holds the wakelock, it would seem that
>>>> almost every other use of the wakelock could (and probably should)
>>>> be replaced by something that tickles the display to stay on longer.
>>>
>>> The problem with this approach is that the display consumes quite a
>>> bit of power, so you don't want to leave it on unnecessarily.  So if
>>> the system is doing something (for example, playing music) that does
>>> not require the display, you really want the display to be off.
>>
>> what percentage (and types) of apps are really useful with the
>> display off. I think that there are relativly few apps that you
>> really want to keep running if the display is off.
>
> The length of time those apps are running is the governing factor
> for battery life, and not the number of such apps, right?

correct, but the number of such apps indicates the scope of the problem.

>From another e-mail tonight it sounds like almost everything already talks 
to a userspace daemon, so if "(the power management service in the
system_server, possibly the media_server and the radio interface
glue)" (plus possibly some kernel activity) are the only things looked at 
when considering if it's safe to sleep or not, all of these can (or 
already do) do 'something' every few seconds, making this problem sound 
significantly smaller than it sounded like before.

Android could even keep it's user-space API between the system power 
daemon and the rest of userspace the same if they want to.

over time, additional apps could be considered 'trusted' (or flagged that 
way by the user) and not have to interact with the power daemon to keep 
things alive.

as for intramentation, the key tool to use to see why a system isn't going 
to sleep would be powertop, just like on other linux systems.

David Lang