Re: [ANNOUNCE] ktimers subsystem

["Christopher Friesen" <cfriesen@nortel.com>]

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