Re: [patch 4/9] Remove the TSC synchronization on SMP machines

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

On Wed, 2007-02-14 at 11:18 +1100, Paul Mackerras wrote:
> Andi Kleen writes:
> 
> > Just to avoid spreading misinformation: modulo some new broken hardware
> > (which we always try to work around when found) i386/x86-64 gettimeofday
> > is monotonic.  AFAIK on the currently known hardware it should be generally
> > ok.
> > 
> > However ntpd can always screw you up, but that's inherent in the design.
> 
> On powerpc we manage to keep gettimeofday monotonic even when ntpd is
> adjusting the clock.  We have 3 parameters used to convert a value
> from the timebase register to the time of day, and these parameters
> are adjusted if necessary at the beginning of each tick, based on the
> value returned by current_tick_length().  The point is that
> current_tick_length() tells you at the *beginning* of each tick how
> much time will be added on to xtime at the *end* of that tick, and
> that makes it possible to aim the interpolation to hit the same value
> as xtime at the end of each tick.
> 
> Clearly if you make a discrete jump backwards with settimeofday or
> adjtime, it's impossible to keep gettimeofday monotonic, but apart
> from that it's monotonic on powerpc.
> 
> At least, that's the way it's supposed to work.  I hope the recent
> timekeeping changes haven't broken it. :)

No. Just to even further clarify (and since everyone is speaking up),
the generic timekeeping does a similar scaling adjustment of the
clocksource frequency for NTP adjustments made via sys_adjtimex().

I believe Andi was just referring to ntpd calling settimeofday(), which
will cause clock_gettime(CLOCK_REALTIME,...)/gettimeofday() to possibly
jump backwards. This behavior of NTP is of course configurable (see the
-x option, or the "tinker step 0" option combined w/ "disable kernel" in
ntp.conf)

-john