On Thu, Feb 26, 2009 at 1:36 PM, Pavel Machek <pavel@xxxxxx> 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@xxxxxx> 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? >From idle, about a second. From suspend, minutes with the radio on, an hour (msm limitation) with the radio off. -- Arve Hjønnevåg _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm