[linux-pm] [PATCH 01/13] PM: Add wake lock api.

[Arve Hjønnevåg]

On Thu, Feb 26, 2009 at 1:36 PM, Pavel Machek <pavel at ucw.cz> wrote:
> On Thu 2009-02-26 13:11:05, Arve Hj?nnev?g wrote:
>> On Thu, Feb 26, 2009 at 7:04 AM, Pavel Machek <pavel at ucw.cz> wrote:
>> > Hi!
>> >
>> >> > It is discouraging to hear comments like "we have been talking about for years something else" yet nothing exists or is in open development. Things can evolve in place.
>> >>
>> >> This is userlad-visible ABI. We can't evolve it in place - we need to
>> >> get it right before merging it, otherwise we need to carry on
>> >> maintaining code for an extended period of time in order to ensure that
>> >> there's no userland code that depends on it.
>> >
>> > Plus... sleepy patches showed that autosuspend can be done *without*
>> > new userland ABIs.
>>
>> As far as I can tell the sleepy patches tries to enter suspend if the
>> system is idle. If you plan to wake back up for the first timer, then
>> the end result of this is the same as what we get by entering the low
>> power state from arch_idle in the msm platform. Due to the frequent
>> wakeups, the power use is higher than our suspend state. If you don't
>> wake up on the first timer, you need something like the wakelock api
>> so apps specify that they need to run even if they were inactive for 3
>> seconds.
>
> You understand it right... it wakes up on first event. So you
> eliminate all the timers that fire too often... and fix userspace if
> neccessary.
>
> Given that your 3rd party apps are written in java, you should have
> enough control over them.

How does the language the apps are written in affect this problem? Are
you saying that java apps should not be allowed to run every second?

> What in-kernel timers are causing problems for you?

I don't know for sure, but last time I checked, the the network stack
woke up every second. /proc/timer_list shows tick_sched_timer always
running in the next second.

> For how long can Android sleep?