Re: AMD X2 unsynced TSC fix?

[thockin@hockin.org]

On Fri, Oct 27, 2006 at 10:18:20PM +0200, Luca Tettamanti wrote:
> Lee Revell <rlrevell@joe-job.com> ha scritto:
> > Someone recently pointed out to me that a Windows "CPU driver update"
> > supplied by AMD fixes the unsynced TSC problem on dual core AMD64
> > systems.
> [...]
> > other incorrect timing effects that these applications may experience on
> > dual-core processor systems, by periodically adjusting the core
> > time-stamp-counters, so that they are synchronized."
> > 
> > What are the chances of Linux getting a similar fix?
> 
> Zero? ;)

Wrong.  We have a fix that has been under serious testing for a long time.

> There's always a window where the TSCs are not in sync (and userspace may
> see a non-monotonic counter); furthermore when C'n'Q is active TSCs
> aren't updated at a fixed frequency, userspace cannot use TSC for timing
> anyway.

Wrong, too.  We have a patch that will be coming SOON (trust me, I am
pushing hard for the author to publish it).  With this patch applied you
should never see the TSC go backwards.  Period.  It should be monotonic
(to userspace, kernel rdtsc calls can still be wrong).  CPUs should stay
very nearly in sync (again, to userspace).  The overhead of this patch is
pretty minimal and costs nothing unless you actually read the TSC.

The catch is that, while it is monotonic, it is not guaranteed to be
perfectly linear.  For many applications, this will be good enough.  Time
will always move forward, and you won't be subject to the weird HZ
granularity gettimeofday that unsynced TSCs can show.

I'm BCCing the author to poke him more publicly.

Tim