Messages in this thread | | | Date | Sat, 7 Feb 2009 10:20:49 +0100 | From | Pavel Machek <> | Subject | Re: [RFC] Dynamic Tick and Deferrable Timer Support |
| |
> > So what I was proposing is that for devices that have timers that would > > allow you to sleep beyond ~2.15 seconds (current max imposed by the > > clockevent_delta2ns function), why not increase the dynamic range (make > > this a 64-bit variable) or base (ie. from nanoseconds to milliseconds) > > to permit longer sleep times for devices that can support them? This > > should not have any negative impact on devices that cannot support such > > long sleep times. > > No objection to max_delta_ns being increased, but whatever code manages > it will probably need to query the timekeeping core in some fashion to > make sure the timer hardware max isn't larger then the clocksource > hardware max. I've provided a rough sketch at what the timekeeping code > would probably look like below. > > > So far I have not encountered any issues with doing this. Let me know if > > this does or does not address your concerns. > > There may be some other issues here, such as NTP over-correction issues > (for instance: ntp trying to correct for a 1us offset over the next > second, but ends up applying it for 10 seconds) if we defer for a really > long time. But at that point, we might as well suspend to ram, like the > OLPC does.
Well, there's still some way to go before auto-sleep is possible. android can do that, afaict, but on pc it is quite far away.
-- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
| |