linux-kernel - Re: AMD X2 unsynced TSC fix?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 27 Oct 2006 16:04:58 -0700
From:	thockin@...kin.org
To:	Luca Tettamanti <kronos.it@...il.com>
Cc:	Lee Revell <rlrevell@...-job.com>, linux-kernel@...r.kernel.org,
	Andi Kleen <ak@...e.de>, john stultz <johnstul@...ibm.com>
Subject: Re: AMD X2 unsynced TSC fix?

On Fri, Oct 27, 2006 at 10:18:20PM +0200, Luca Tettamanti wrote:
> Lee Revell <rlrevell@...-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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/