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]

Message-ID: <Pine.LNX.4.64.0610301228180.21619@schroedinger.engr.sgi.com>
Date:	Mon, 30 Oct 2006 12:30:58 -0800 (PST)
From:	Christoph Lameter <clameter@....com>
To:	thockin@...kin.org
cc:	Luca Tettamanti <kronos.it@...il.com>,
	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, 27 Oct 2006, thockin@...kin.org wrote:

> 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.

Well why not use regular clock_gettime() instead? If you add code for TSC 
processing (intercepting RDTSC from user space???)  then it may be 
comparable in performance to time retrieval via POSIX calls using 
vsyscalls. Look like you may start duplicating the time subsystem?


-
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/