Re: [RFC][PATCH] HZ as a config option

[george anzinger <george@mvista.com>]

Dave Hansen wrote:
> 
> Alan Cox wrote:
> > On Fri, 2002-10-04 at 23:53, Dave Hansen wrote:
> >
> >>On large systems (like NUMA-Q, Intel Profusion, etc...), latency and
> >>user responsiveness become much less important.  The extra scheduling
> >>overhead caused by higher HZ is bad.
> >>
> >>This is x86-only right now.  Is there any wider desire to tune this at
> >>config time?  Do any architecutures have strict rules as to what this
> >>can be set to?
> >
> > You can't set this arbitarily, the NTP PLL's will only lock for certain
> > value ranges.
> 
> Where can I find these ranges?  include/linux/timex.h only errors if
> the number is out of the 12-1535 range.

The issue is not the value itself, but if, by using the
value and the PIT with its clock of 14.3181818/12 MHZ you
can come up with a count that is ?? parts per million of
being right.  I am not sure what ?? should be but 20 comes
to mind.

All this is (incorrectly) covered over in 2.5 by using a
more "correct" value for tick_nsec.  This keeps the wall
clock correct for most any value of HZ, BUT breaks the POSIX
standard that says NO TIMER SHALL EXPIRE BEFORE ITS TIME. 
To prove this breakage, try this on a 2.5 system:

time sleep 60

Any answer less than 1 minute is BROKEN.

I think the correct way to do all this is to use something
other than the PIT as the clock reference AND adjust the
jiffies time, not the wall clock.  

The High-res-timers patch I posted last Friday does the
first part, i.e. uses a different clock reference.  The NTP
changes will come later.

-g
> 
> -
> 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/

-- 
George Anzinger   george@mvista.com
High-res-timers: 
http://sourceforge.net/projects/high-res-timers/
Preemption patch:
http://www.kernel.org/pub/linux/kernel/people/rml