Re: [patch] jiffies wraparound [Re: 2.1.125 Show stopper list: Draft]

[Jim Gettys]

-
> Sender: [e-mail]
> From: Olivier Galibert <[e-mail]>
> Date: 	Sat, 24 Oct 1998 02:54:41 +0200
> To: [e-mail]
> Subject: Re: [patch] jiffies wraparound [Re: 2.1.125 Show stopper list: Draft]
> -----
> On Fri, Oct 23, 1998 at 05:44:57PM -0300, Paul Barton-Davis wrote:
> > This is silly. Applications that use the kernel to provide a
> > user-level clock via setitimer() are limited by the kernel value as
> > is, and to say that even if the kernel value increases, they should
> > never, ever try to take advantage of it seems strangely un-Linux like
> > to me. Don't we want applications to be able to work as well as
> > possible ? If I have a box capable of support HZ=1000, then my user
> > level application can reasonably ask for an itimer of < 10ms. If the
> > value of HZ=100, this makes no sense, and causes erratic timing
> > behaviour in the application. Why is it so wrong to be able to ask
> > "whats the minimum value for a timer that makes sense ?", which is
> > effectively a function of HZ ?
> 
> The setitimer  resolution is not defined  to  be HZ.  It  is perfectly
> reasonable  to  think that   in  the  future,  with the   increase  of
> soft-RTism in the kernel, timers will be automagically adapted to give
> the best precision available to such timers.
> 
> Face it, HZ is obsolete.  You don't want a 10ms (or 1ms) resolution on
> everything you do anymore.  You want  the shortest possible latency on
> events (which mainly means  rescheduling after interrupts and/or IPCs)
> for   good interactive  behaviour.   You    want  long timeslices   on
> cpu-burning   processes to  reduce  cache effects.    You want precise
> timers.  Saying that HZ rules them all is innefficient.
> 

Many other systems have been running with a much higher than 100hz basic
clock rate for a long time.

Its been a while, so this is from memory...

On MIPS/Ultrix, for example, if memory serves, we ran at a 4 millisecond
tick (250hz).

On Digital UNIX, I believe the basic internal clock is running at 1
millisecond (1000hz).

Basically, running the schedular more often is goodness, until it takes
a significant amount of overhead.  I believe we did some experiments
when the basic ports were done to those systems and figured that if
it took less than 1% of the CPU, things were golden.  I may be wrong,
but it may even be a run time option in Digital UNIX at this point
(it is certainly a compile time parameter).

Given the current speed of machines, (and even now obsolete machines;
a MIPS/Ultrix system started life at 12MHZ), a higher clock rate
has been feasible for a long time.

Along the way, you get better behavior for select, for performance
measurement, better responsiveness for scheduling,
for anything having to do with time.
				- Jim