Re: Why HZ on i386 is 100 ?

[george anzinger <george@mvista.com>]

Alan Cox wrote:
> 
> > > We do anyway
> >
> > Yes, but now we do all this in the timer tick, not in schedule().  This
> > occures much less often.
> 
> Well in the timer tick code we already hold the locks needed to check
> the front of the timer queue safely, we already have current and the top
> timer needing to touch cache (current for accounting stats at the least).
> So thats what an extra compare and cmov - 1 clock maybe 2 ?

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

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.
-- 
George Anzinger   george@mvista.com
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
Real time sched:  http://sourceforge.net/projects/rtsched/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml