[lkml]   [2005]   [Sep]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [ANNOUNCE] ktimers subsystem
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.


> It's not just high resolution aware, it makes all calculation in high
> resolution _unconditionally_, which makes it high resolution all the way.


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

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-09-23 01:34    [W:0.088 / U:0.652 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site