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 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? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
