[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 14 Feb 2007 11:18:44 +1100
From: Paul Mackerras <paulus@...ba.org>
To: Andi Kleen <ak@...e.de>
Cc: Christoph Lameter <clameter@....com>,
Arjan van de Ven <arjan@...radead.org>,
Vojtech Pavlik <vojtech@...e.cz>, Jiri Bohac <jbohac@...e.cz>,
linux-kernel@...r.kernel.org, ssouhlal@...ebsd.org,
tglx@...utronix.de, johnstul@...ibm.com, zippel@...ux-m68k.org,
andrea@...e.de
Subject: Re: [patch 4/9] Remove the TSC synchronization on SMP machines
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. :)
Paul.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists