Re: [patch 00/43] ktimer reworked

[Kyle Moffett <mrmacman_g4@mac.com>]

On Dec 01, 2005, at 19:29, Roman Zippel wrote:
> Hi,
>
>> As for portablility, I believe John Stultz has some nice plugins  
>> coming to what timer source you want to use, so if there's a  
>> better way to get a time, these should make things easy to add.
>
> These plugins can do no magic, if the hardware timer is slow, the  
> whole thing gets slow.

The point is that you could switch both the timer and timeout  
implementations to jiffies if you wanted to, at the expense of the  
accuracy that a lot of people care about.

>>> - resolution: how precise must the timer be? jiffies can't  
>>> represent time values less than 1ms, but if time is e.g. measured  
>>> in 10th of a second, jiffies may be enough.
>>
>> And they would be if that is all you need. But coming from an  
>> embedded point of view, that is not nearly enough.  I really see  
>> HighRes making it into the kernel soon, and any new code in this  
>> area really needs to take that into account.
>
> I'm not against HR timer, I have a problem with using them as timer  
> for everything.

This is _exactly_ why there is the timer/timeout distinction.  Some  
things don't care, and as a result use a timer wheel exactly like  
they always have.  For the things that do, however, the new timer API  
provides it using the fastest hardware interface available.

Cheers,
Kyle Moffett

--
I didn't say it would work as a defense, just that they can spin that  
out for years in court if it came to it.
   -- Rob Landley