On Thu, 14 Jul 2005, Alan Cox wrote:
>
> I suspect the problem for some of this is that people think of jiffies
> as incrementing by 1. If HZ is right then jiffies can be in nS, it just
> won't increment by 1.
No, jiffies _cannot_ be in nS, because of the fact that then it doesn't
fit in a word any more. A lot of things want timeouts in the tens of
minutes, and a jiffy clock that tries to ne in nS just screws that up
entirely, and forces people to use u64.
Which is much more expensive to compare on 32-bit architectures due to
nasty atomicity issues.
So you want to keep the "normal" timeout 32-bit. In ten years we may not
care any more. For the forseeable future we definitely do.
> Its also why jiffies() is better on some platforms
> because many machines can answer "what time is it" far more accurately
> than they can set interrupts.
That's not what "jiffies" are about. If you want accurate time, use
something else, like gettimeofday. The timeouts are _only_ relevant on the
scale of a timer interrupt, since by definition that's what we're waiting
for.
So accuracy is a total non-issue. The only kind of accuracy we care about
is "how often can the timer ticks happen".
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
