From owner-svn-src-all@FreeBSD.ORG Fri Jun 22 07:48:37 2012 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB4651065670; Fri, 22 Jun 2012 07:48:36 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 7663D8FC15; Fri, 22 Jun 2012 07:48:36 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q5M7mHXN093337; Fri, 22 Jun 2012 10:48:17 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q5M7mHEb040779; Fri, 22 Jun 2012 10:48:17 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q5M7mHvo040778; Fri, 22 Jun 2012 10:48:17 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 22 Jun 2012 10:48:17 +0300 From: Konstantin Belousov To: Marius Strobl Message-ID: <20120622074817.GA2337@deviant.kiev.zoral.com.ua> References: <201206220713.q5M7DVH0063098@svn.freebsd.org> <20120622073455.GE69382@alchemy.franken.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BhCmZxNx01sRldsR" Content-Disposition: inline In-Reply-To: <20120622073455.GE69382@alchemy.franken.de> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua 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 X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2012 07:48:37 -0000 --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--