From owner-svn-src-all@FreeBSD.ORG Sat Jun 23 14:06:02 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 A96A2106566B; Sat, 23 Jun 2012 14:06:02 +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 3EFA48FC1E; Sat, 23 Jun 2012 14:06:02 +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 q5NE5u5x076827; Sat, 23 Jun 2012 17:05:56 +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 q5NE5uWm063779; Sat, 23 Jun 2012 17:05:56 +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 q5NE5uFC063778; Sat, 23 Jun 2012 17:05:56 +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: Sat, 23 Jun 2012 17:05:56 +0300 From: Konstantin Belousov To: Marius Strobl Message-ID: <20120623140556.GU2337@deviant.kiev.zoral.com.ua> References: <201206220713.q5M7DVH0063098@svn.freebsd.org> <20120622073455.GE69382@alchemy.franken.de> <20120622074817.GA2337@deviant.kiev.zoral.com.ua> <20120623131757.GB46065@alchemy.franken.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="x5H/dHEtcMgsAT6y" Content-Disposition: inline In-Reply-To: <20120623131757.GB46065@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: Sat, 23 Jun 2012 14:06:02 -0000 --x5H/dHEtcMgsAT6y Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jun 23, 2012 at 03:17:57PM +0200, Marius Strobl wrote: > On Fri, Jun 22, 2012 at 10:48:17AM +0300, Konstantin Belousov wrote: > > 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? > >=20 > > Generally speaking, tsc state among different CPU after boot is not > > synchronized, you are right. > >=20 > > 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. >=20 > Okay, so for x86 the TSCs are not used as timecounters by either > the kernel or userland in the SMP case if they don't appear to > be synchronized, correct? Correct as for now. But this is bug and not a feature. The tscs shall be synchronized, or skew tables calculated instead of refusing to use it. >=20 > >=20 > > 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 ? >=20 > The TICK counters are per-core and not synchronized by the hardware. > We synchronize APs with the BSP on bring-up but they drift over time > and the initial synchronization might not be perfect in the first > place. At least in the past, drifting TICK counters caused all sorts > of issues and strange behavior in FreeBSD when used as timecounter > in the SMP case. If my understanding of the above is right, as is > this still rules them out as timecounters for userland. > Linux has some complex code (based on equivalent code origining in > their ia64 port) for constantly synchronizing the TICK counters. > In order to avoid that complexity and overhead, what I do in > FreeBSD in the SMP case is to (ab)use counters (either intended > for that purpose or bus cycle counters probably intended for > debugging the hardware during development) available in the > various host-to-foo bridges so it doesn't matter which CPU they > are read by. This works just fine except for pre-PCI-Express > based USIIIi machines, where the bus cycle counters are broken. > That's where the TICK counter is always read from the BSP > using an IPI in the SMP case. The latter is done as sched_bind(9) > isn't possible with td_critnest > 1 according to information > from jhb@ and mav@. > So apart from introducing code to constantly synchronize the > TICK counters, using the timecounters on the host busses also > seems to be the only viable solution for userland. The latter > should be doable but is long-winded as besides duplicating > portions of the corresponding device drivers in userland, it > probably also means to get some additional infrastructure > like being able to memory map registers for devices on the > nexus(4) level in place ... Understand. I do plan eventually to map HPET counters page into usermode on x86. Also, as I noted above, some code to synchronize per-package counters would be useful for x86, so it might be developed with multi-arch usage in mind. --x5H/dHEtcMgsAT6y Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk/lzUQACgkQC3+MBN1Mb4jrTwCgjeoJh5/3fqsZBgaU+F4o3bou yg8An2Ac82EdegqYqBYGUVZhiyI6NuzC =fGTg -----END PGP SIGNATURE----- --x5H/dHEtcMgsAT6y--