On Thu, 14 Jul 2005, Alan Cox wrote:
>
> > just doesn't realize that the latter is a bit more complicated exactly
> > because the latter is a hell of a lot more POWERFUL. Trying to get rid of
> > jiffies for some religious reason is _stupid_.
>
> Getting rid of jiffies in its current form is a huge win for very
> non-religious reasons. Jiffies is expensive in power management and
> virtualisation because you have to maintain it.
No, you're now confusing "interrupts" with "jiffies".
There is no conceptual 1:1 thing between those two.
It so happens that traditionally we've kept them 1:1, but there's nothing
that says that we can't slow down the interrupt source and just increment
jiffies by a factor of the slowdown when the interrupt _does_ happen.
But no, that does NOT mean that "jiffies" should just count nanoseconds,
and the problem would be solved. The fact is, most users of jiffies only
care about the low 32 bits on 32-bit architectures, and that's fine as
long as jiffies are in the millisecond range, since it still leaves a
useful timeout value for almost everything (and then only long-range stuff
needs to use "u64" for their timeouts).
In other words, we want a clock that is _known_ to not be very accurate,
but that is easy to just read from a memory location, and that has some
relationship to a timer tick in the sense that it should be at least in
the order-of-magnitude range for what a timer tick can cause.
Anybody who asks for nanoseconds is confused. That just forces you to use
a 64-bit value, where no such value is needed. Things like TCP
retransmission timeouts would be totally _idiotic_ to be made in
nanoseconds: it would just make the socket data structures larger, and it
has zero relevance, since the actual timer tick doesn't have that kind of
resolution _anyway_.
The current "jiffies" actually fits all of these problems _wonderfully_
well. Yes, it needs to be converted from "struct timeval" and friends, but
it needs to be converted exactly _because_ of the good properties it has,
namely that it fits in a word, and is _relevant_ to what a timer interrupt
ends up being.
Look at 99% of the use of jiffies: it uses _jiffies_. It doesn't use
"jiffies_64", even though that's actually what gets updated. And it does
that _exactly_ because almost _nobody_ cares to pay the price of 64 bit
issues (both structure memory usage, and atomicity costs on 32-bit
architectures).
And I claim that you _cannot_ do better.
But what you can do is to have HZ at some reasonably high value (ie in the
kHz range), and then slow down the system clock to conserve energy, and
increment jiffies by 16 or 32 when in "slow clock mode". And then, when
there is a multimedia app or somethign that asks for high-precision
timers, you speed the interrupts up again, and you increment jiffies by 1.
It's that simple. And it really _is_ simple.
And guys, the fact is, jiffies works _today_. Making this change won't
break anything, and won't introduce any new concepts, and won't break any
existing drivers. In contrast, introducing _yet_ another timekeeping
mechanism is not only going to be objectively _worse_ than jiffies from a
technical standpoint, it's going to be a total disaster from a transition
standpoint too.
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |