Re: suspend blockers & Android integration

[Arjan van de Ven]

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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/