Re: Linux-Kernel Archive: No 100 HZ timer !

["Mark Salisbury" <gonar@mediaone.net>]

> I think it makes the most sense to keep jiffie as a simple unsigned
> int.  If we leave drivers, and other code as is they can deal with
> single word (32 bit) values and get reasonable results.  If we make HZ
> too high (say 10,000 to get micro second resolution) we will start
> limiting the max time we can handle, in this case to about 71.5 hours.
> (Actually 1/2 this value would start giving us trouble.)  HZ only
> affects the kernel internals (the user API is either seconds/micro
> seconds or seconds/nano seconds).  For those cases where we want a higer
> resolution we just add a sub jiffie component.  Another way of looking
> at this is to set up HZ as the "normal" resolution.  This would be the
> resolution (as it is today) of the usual API calls.  Only calls to the
> POSIX 1b timers would be allowed to have higher resolution.  I propose
> that we use the POSIX standard to define "CLOCKS" with various
> resolution, with the understanding that the higher resolutions will have
> higher overhead.  An yet another consideration, to get high resolution
> with a reasonable maximum timer interval we will need to use two words
> in the timer.  I think it makes sense to use the jiffie (i.e. 1/HZ) as
> the high order part of the timer's time.
>
> Note that all of these considerations on jiffie size hold with or with
> out a tick less system.

inner loop, i.e. interrupt timer code should never have to convert from some
real time value into number of decrementer ticks in order to set up the next
interrupt as that requires devides (and 64 bit ones at that) in a tickless
system.

this is why any variable interval list/heap/tree/whatever should be kept in
local ticks.  frequently used values can be pre-computed at boot time to
speed up certain calculations (like how many local ticks/proc quantum)