Date: Fri, 22 Jun 2012 08:41:38 +0100 From: David Chisnall <theraven@theravensnest.org> To: Marius Strobl <marius@alchemy.franken.de> Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, Konstantin Belousov <kib@FreeBSD.org> Subject: Re: svn commit: r237434 - in head/lib/libc: amd64/sys gen i386/sys include sys Message-ID: <D97ED5E0-B1BF-4328-B8A0-7546D74912A2@theravensnest.org> In-Reply-To: <20120622073455.GE69382@alchemy.franken.de> References: <201206220713.q5M7DVH0063098@svn.freebsd.org> <20120622073455.GE69382@alchemy.franken.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On 22 Jun 2012, at 08:34, Marius Strobl wrote: > I don't know much about x86 CPUs but is my understanding correct > that TSCs are not synchronized in any way across CPUs, i.e. > reading it on different CPUs may result in time going backwards > etc., which is okay for this application though? As long as the initial value is set on every context switch, it only matters that the TSC is monotonic and increments at an approximately constant rate. It is also possible to set the TSC value, but that's less useful in this context. The one thing to be careful about is the fact that certain power saving states will affect the speed at which the TSC increments, and so it is important to update the ticks-per-second value whenever a core goes into a low power state. This is more or less the same approach used by Xen, so most of the issues have been ironed out: Oracle complained to CPU vendors about a few corner cases and, because Oracle customers tend to buy a lot of expensive Xeon and Opteron chips, they were fixed quite promptly. David
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D97ED5E0-B1BF-4328-B8A0-7546D74912A2>