Messages in this thread | | | Date | Fri, 27 Oct 2006 16:04:58 -0700 | From | thockin@hockin ... | Subject | Re: AMD X2 unsynced TSC fix? |
| |
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |