Re: HZ, preferably as small as possible

mbs (mbs@mc.com)
Mon, 15 Jul 2002 15:52:37 -0400


On Monday 15 July 2002 14:56, Linus Torvalds wrote:
> On 15 Jul 2002, Robert Love wrote:
> > A cleaner solution to this issue is a higher resolution timer, e.g. the
> > high-res-timers project which has high resolution POSIX timers.
>
> But that really doesn't solve the problem either.
>
> You still need to have some limit on the timer resolution. Whether you
> call that limit "HZ" or something else is irrelevant in the end. Just
> calling them "high-resolution" doesn't make the problem go away, you still
> have some resolution (*).
>
> So once you set some magic limit on the fine-grained resolution (let's
> call that "MAX_FINE_HZ"), you might as well realize that that really is
> 100% equivalent to just making HZ _be_ that value. Together with possibly
> making the actual timer tick happen at a slower rate according to some
> other heuristics (ie "the system doesn't need timers right now, let's just
> not do them").
>
> Linus
>
> (*) Which is a lot less than the hw can generate, since you mustn't allow
> users to bog down the system in timer interrupts by just using
> "itimer(ITIMER_REAL, .. fine-resolution..)".

actually, that is an interesting philosophical argument.

in an embedded system, it is sometimes more useful to not put artificial
constraints on the system and allow the clock and timer system to work in hw
increments, but document the hell out of it.

this is the "give 'em enough rope to hang themselves, but tell them the
precise length of the rope" model.

in an embedded system a "tickless" system is sometimes preferable to a ticked
system. there is often only one or a very small number of processes/threads
running and the extra overhead of 10 surplus clock ticks per process quantum
is a waste of cycles. (also when using a ppc or similar modern chip(flame
on;-), there is no need to keep a software wall clock, as the cpu has a 64bit
free running counter)

I had this discussion with george A. early in the posix timers project and I
argued/begged for a compile time config option giving the option of ticked
and tickless versions. George chose to go with a ticked system, because it
benchmarked better in a general purpose system, particlularly under high
loads, and he didn't have time to implement two systems. he made the right
choice for the general purpose kernel and for probably 80% of the embedded
market. (I'm in the other 20%)

-- 
/**************************************************
**   Mark Salisbury       ||      mbs@mc.com     **
**************************************************/
-
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/