Re: [patch 00/43] ktimer reworked

[Kyle Moffett]

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



-
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/