timer slack

From: david
Date: Mon Oct 17 2011 - 19:27:41 EST


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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/