Re: [ANNOUNCE] ktimers subsystem

[Roman Zippel <zippel@linux-m68k.org>]

Hi,

On Thu, 22 Sep 2005, Christopher Friesen wrote:

> 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 hoped for a more concrete example (i.e. pointer to source), but this one 
at least gave me enough hints where to look.
There are ways to avoid this huge number of added timers, but this 
requires a better analysis of the problem.

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

Actually the decision to use ns has nothing to do with API issues. 
<linux/jiffies.h> has already a lot of options to specify timeouts for 
kernel timer. The official userspace API is mostly timespec/timeval.
The nsec_t type is an _internal_ type to manage time, so this makes it 
possible to do something like this:

#ifdef CONFIG_HIRES_TIMER
typedef u64 ktime_t;
#else
typedef u32 ktime_t;
#endif

bye, Roman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/