On Sat, 5 Jun 2010 14:26:14 -0700 Arve Hjønnevåg <arve@xxxxxxxxxxx> wrote: > On Sat, Jun 5, 2010 at 9:28 AM, Arjan van de Ven > <arjan@xxxxxxxxxxxxx> wrote: > > On Sat, 05 Jun 2010 11:54:13 +0200 > > Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote: > > > >> On Fri, 2010-06-04 at 17:10 -0700, Arve Hjønnevåg wrote: > >> > > Trusted processes are assumed to be sane and idle when there is > >> > > nothing for them to do, allowing the machine to go into deep > >> > > idle states. > >> > > > >> > > >> > Neither the kernel nor our trusted user-space code currently > >> > meets this criteria. > >> > >> Then both need fixing. Really, that's the only sane approach. > > > > fwiw... in MeeGo we're seeing quite good idle times (> 1 seconds) > > without really bad hacks. > > > > We clearly have different standards for what we consider good. We > measure time suspended in minutes or hours, not seconds, and waking up > every second or two causes a noticeable decrease in battery life on > the hardware we have today. I guess I'm spoiled working with (unreleased) hardware that knows how to power gate ;-) > > > the kernel has a set of infrastructure already to help here (range > > timers, with which you can wakeup-limit untrusted userspace crap), > > timer slack for legacy background timers, etc etc. > > Range timers allows the kernel to align different timers so they don't > each bring the cpu out of idle individually. They do not eliminate > timers or make individual timers fire less often. you're incorrect. With range timers you can control the rate at which timers fire just fine. For example if the Adobe Flash player puts a timer every 10 milliseconds (yes it does that), and you give it a 3.99 seconds range, it will fire its timers every 4 seconds.... unless other activity happens independently, at which point it'll align with that instead. -- Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
