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. =20 David
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D97ED5E0-B1BF-4328-B8A0-7546D74912A2>