Re: Why HZ on i386 is 100 ?

[Alan Cox]

> The problem is the extra code in the schedule() path, not in the timer
> tick path.  It is traversed FAR more often.

Thats still in most cases a single compare. The tick timer will mostly be
going off before our time slice completes. Also importantly the more we
context switch the less timers go off - so it scales correctly.

> The current tick at 1/HZ is really quite relaxed.  Given the PIT (ugh!)
> the longest we can put off a tick is about 50 ms.  This means that any
> time greater than this will require more than one interrupt, i.e. the
> best case improvement by going tick less (again given the PIT) is about
> 5 times.  Other platforms/ hardware, of course, change this.

If you are arguing that the PIT makes it impractical on basic x86 then
we are in violent agreement. I don't propose this kind of stuff for the
PIT but for real computers where a timer reload is a couple of clocks