Re: [RFC] HZ free ntp

[john stultz <johnstul@us.ibm.com>]

On Wed, 2006-12-13 at 10:51 +0100, Ingo Molnar wrote:
> * john stultz <johnstul@us.ibm.com> wrote:
> 
> > On Wed, 2006-12-06 at 15:33 +0100, Roman Zippel wrote:
> > > On Wed, 6 Dec 2006, Ingo Molnar wrote:
> > > > i disagree with you and it's pretty low-impact anyway. There's still
> > > > quite many HZ/tick assumptions all around the time code (NTP being one
> > > > example), we'll deal with those via other patches.
> > >
> > > Why do you pick on the NTP code? That's actually one of the places where
> > > assumptions about HZ are largely gone. NTP state is updated incrementally
> > > and this won't change, but the update frequency can now be easily
> > > disconnected from HZ.
> >
> > Hey Roman,
> > 	Here's my rough first attempt at doing so. I'd not call it easy, but
> > maybe you have some suggestions for a simpler way?
> >
> > Basically INTERVAL_LENGTH_NSEC defines the NTP interval length that
> > the time code will use to accumulate with. In this patch I've pushed
> > it out to a full second, but it could be set via config
> > (NSEC_PER_SEC/HZ for regular systems, something larger for systems
> > using dynticks).
> 
> cool! I'll give this one a go in -rt, combined with the exponential
> second-overflow patch. (that one is now algorithmically safe, right?)

No, this one will replace the exponential accumulation patch. So we'll
accumulate on second intervals, which should be far enough apart that we
won't be spinning in that loop for long.

thanks
-john