Date: Fri, 22 Jun 2012 10:48:17 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Marius Strobl <marius@alchemy.franken.de> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r237434 - in head/lib/libc: amd64/sys gen i386/sys include sys Message-ID: <20120622074817.GA2337@deviant.kiev.zoral.com.ua> 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
--BhCmZxNx01sRldsR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jun 22, 2012 at 09:34:56AM +0200, Marius Strobl wrote: > On Fri, Jun 22, 2012 at 07:13:31AM +0000, Konstantin Belousov wrote: > > Author: kib > > Date: Fri Jun 22 07:13:30 2012 > > New Revision: 237434 > > URL: http://svn.freebsd.org/changeset/base/237434 > >=20 > > Log: > > Use struct vdso_timehands data to implement fast gettimeofday(2) and > > clock_gettime(2) functions if supported. The speedup seen in > > microbenchmarks is in range 4x-7x depending on the hardware. > > =20 > > Only amd64 and i386 architectures are supported. Libc uses rdtsc and > > kernel data to calculate current time, if enabled by kernel. >=20 > 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? Generally speaking, tsc state among different CPU after boot is not synchronized, you are right. Kernel has somewhat doubtful test which verifies whether the after-boot state of tsc looks good. If the test fails, TSC is not enabled by default as timecounter, and then usermode follows kernel policy and falls back to slow syscall. So we err on the safe side. I tested this on Core i7 2xxx, where the test (usually) passes. The test we currently have fails for me at least on single-package Nehalems, where the counter should be located on uncore part. This indicates some brokeness in the code, but I did not investigated the cause. The code can be developed which adjusts tsc msrs to be in sync. Or, rtdscp instruction can be used, which allow to handle counter skew in usermode in race-free manner. While you are there. do you have comments about sparc64 TICK counter ? On SMP, the counter of BSP is used by IPI. Is it unavoidable ? --BhCmZxNx01sRldsR Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk/kI0EACgkQC3+MBN1Mb4jh9QCgnhWmDbvxGgbSNaOSUQ98p/wZ 5GIAnApRbgba9UHQIdftXy8A4CmfAAYH =kE+o -----END PGP SIGNATURE----- --BhCmZxNx01sRldsR--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120622074817.GA2337>