Date:	Mon, 17 Oct 2011 16:27:39 -0700 (PDT)
From:	david@...g.hm
To:	linux-kernel <linux-kernel@...r.kernel.org>
Subject: timer slack

apologies for breaking threading, but I missed the messages on this 
thread, but wanted to comment after seeing the article on LWN

I don't believe that the idea of 'fix the apps' is reasonable. The apps 
are not the right places to put the fixes for a number of reasons.

First:

even if the apps do all properly put themselves into an appropiate 
'background/inactive' status, there are sitll a number of reasons for apps 
to wake up on a periodic basis to do things

check for alarms

check battery life

sample some real-world value (including location)

check for new mail

etc

these things are all scheduled by each app indepndantly of each other, and 
as a result, each one is likely to cause a separate wakeup event. If the 
timer slack was lengthened to 60 seconds it is far more likely that all 
such wakeups could be processed at once.


Second:

the appropriate amount of delay is not fixed for each application, it can 
depend on a lot of different conditions, for example:

is the device on external power, and external screen, etc (aka acting as a 
desktop replacement)?

if the device on battery power?

is the battery <10% (where the user may want to delay wakeups much longer, 
accepting things being less up to date in exchange for stretching the 
remaining battery life)

these sorts of policies should not be put into each application, but this 
fits very nicely with a system-wide power management tool (that already 
decides when to dim the screen, pause the system, hibernate, power down 
completely, etc)


the assumption from the discussion seems to be that all apps on a system 
will be in the same cgroup and therefor follow the same rules. nothing 
says that this must be the case. I could easily see having multiple groups 
for different purposes (alarms vs background data sync tasks for example)


All of this is completely separate from the argument that trying to get 
every programmer in the world to fix their application is a lost cause.

remember that not every application programmer is planning for their 
application to run on a power constrained device.

not every application programmer is planning for their application to run 
on Linux (at least not to the point of being willing to put linux-specific 
system calls and power management features in it)

don't assume that all applications that run on mobile devices are going to 
be ones written with that as their primary focus. With today's available 
systems this is usually the case, but it does not need to be.


Personally, I strongly suspect that agressive timer slack with userspace 
management could get power savings similar to (or better than) what 
android gets from userspace wakelocks. Today there isn't a good way to try 
this, I would love to have something like this available to test and see 
if I am right.

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