Re: [RFC] HZ free ntp

[Roman Zippel <zippel@linux-m68k.org>]

Hi,

On Tuesday 02 January 2007 20:42, john stultz wrote:

> > tick_nsec doesn't require special treatment, in the middle term it's
> > obsolete anyway, it could be replaced with (current_tick_length() >>
> > TICK_LENGTH_SHIFT) and current_tick_length() being inlined.
>
> If NTP_INTERVAL_FREQ is different then HZ, then tick_nsec still has a
> different meaning then (current_tick_length() >> TICK_LENGTH_SHIFT).
> So since tick_nsec is still used in quite a few places, so I'm hesitant
> to pull it.

The current usage under arch is pretty much bogus and they likely can't use 
dyntick anyway, so it would be easier to disable tick_nsec completely if 
dyntick is enabled.

> > NTP_INTERVAL_FREQ could be a real variable (so it can be initialized at
> > runtime), it's already gone from all important paths.
>
> Wait, so you're suggesting NTP_INTERVAL_FREQ be a dynamic variable
> instead of a constant? Curious, could you give a bit more detail on why?

We already have more than enough config options, where the user has barely any 
idea what to do, so we should try to configure and initialize as much as 
possible at runtime depending on what the hardware is capable of.

That reminds me that the main problem left for a dynamic variable is 
time_offset. It should become a 64 bit value, so SHIFT_UPDATE isn't needed 
anymore. Right now it depends on HZ to maximize the value range.

> > In the short term I'd prefered a clock would store its frequency instead
> > of using NTP_INTERVAL_LENGTH in clocksource_calculate_interval(), so it
> > doesn't has to be derived there.
>
> I don't follow this at all. clocksources do store their own frequency
> (via mult/shift). Could you explain?

mult is not a constant and calculating the frequency like this is not very 
precise.

bye, Roman