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

[Arve Hjønnevåg]

On Fri, Feb 27, 2009 at 1:56 AM, Pavel Machek <pavel at ucw.cz> wrote:
> Hi!
>
>> >> 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?
>
> I'm trying to say that you have pretty good control over java apps. So

I'm trying to say that we do not.

> you could for example make them call modified select with sloppiness,
> or make them set their own sloppiness etc...
>
>> > 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.
>
> I went through those in minimal system, and was able to mostly solve
> that. Can we simply get network stack (etc) fixed?

If you have fixes to eliminate polling in the network stack, please
submit them (unless you already have) as this would benefit every
system. Even if you eliminate all polling in the kernel, and the
platform supports the same low power state from idle, I still think
suspend is a useful way to pause the entire system when it does not
need to run.

-- 
Arve Hjønnevåg