Roman Zippel wrote:
This no answer at all, you only repeat what you already said above. :(
Care to share your knowledge?
Ingo already gave an example. "a busy network server can easily have
millions of timers pending. I once had to increase a server's 16 million
tw timer sysctl limit ..."
I don't say that 64bit math is evil, I just question that it's required -
small, but important difference.
<snip>
It's not just high resolution aware, it makes all calculation in high
resolution _unconditionally_, which makes it high resolution all the way.
<snip>
What unprovable claims? What would change in the basic principles, if you
would do them with 32bit ms values instead of 64bit ns values? The basic
math should be the same and should demonstrate the basic principles
equally well and since the current timer code has only ms (at HZ=1000)
precision the behaviour should be the same as well.
I see two assumptions that lead to the API using nanoseconds:
1) it is desireable to have a human-time-unit timer API, so that people
can specify timeouts in easily-understood units
2) eventually we will use sub-ms resolution timers, so it makes sense to
just jump to nanoseconds as our base timing unit
Are these reasonable starting points, or is there disagreement on these?
Maybe it would make sense to have the API be in nanoseconds and
internally use 32bit ms for now, and only change to 64bit nanos when we
actually move to sub-ms resolution timers.
Chris
-
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]
| |
 |