From owner-svn-src-head@FreeBSD.ORG Wed Jul 25 10:21:37 2012 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 34B5B1065672; Wed, 25 Jul 2012 10:21:37 +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 C22DF8FC12; Wed, 25 Jul 2012 10:21: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 q6PALgsi019427; Wed, 25 Jul 2012 13:21:42 +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 q6PALU8M087580; Wed, 25 Jul 2012 13:21:30 +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 q6PALUmj087579; Wed, 25 Jul 2012 13:21:30 +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: Wed, 25 Jul 2012 13:21:30 +0300 From: Konstantin Belousov To: Andriy Gapon Message-ID: <20120725102130.GH2676@deviant.kiev.zoral.com.ua> References: <201207242210.q6OMACqV079603@svn.freebsd.org> <500F9E22.4080608@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1Dj3cEIIrBZAiNOW" Content-Disposition: inline In-Reply-To: <500F9E22.4080608@FreeBSD.org> 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, Jim Harris , svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r238755 - head/sys/x86/x86 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 10:21:37 -0000 --1Dj3cEIIrBZAiNOW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 25, 2012 at 10:20:02AM +0300, Andriy Gapon wrote: > on 25/07/2012 01:10 Jim Harris said the following: > > Author: jimharris > > Date: Tue Jul 24 22:10:11 2012 > > New Revision: 238755 > > URL: http://svn.freebsd.org/changeset/base/238755 > >=20 > > Log: > > Add rmb() to tsc_read_##x to enforce serialization of rdtsc captures. > > =20 > > Intel Architecture Manual specifies that rdtsc instruction is not ser= ialized, > > so without this change, TSC synchronization test would periodically f= ail, > > resulting in use of HPET timecounter instead of TSC-low. This caused > > severe performance degradation (40-50%) when running high IO/s worklo= ads due to > > HPET MMIO reads and GEOM stat collection. > > =20 > > Tests on Xeon E5-2600 (Sandy Bridge) 8C systems were seeing TSC synch= ronization > > fail approximately 20% of the time. >=20 > Should rather the synchronization test be fixed if it's the culprit? Synchronization test for what ? > Or is this change universally good for the real uses of TSC? What I understood from the Intel SDM, and also from additional experiments which Jim kindly made despite me being annoying as usual, is that 'read memory barrier' AKA LFENCE there is used for its secondary implementation effects, not for load/load barrier as you might assume. According to SDM, LFENCE fully drains execution pipeline (but comparing with MFENCE, does not drain write buffers). The result is that RDTSC is not started before previous instructions are finished. For tsc test, this means that after the change RDTSC executions are not reordered on the single core among themself. As I understand, CPU has no dependency noted between two reads of tsc by RDTSC, which allows later read to give lower value of counter. This is fixed by Intel by introduction of RDTSCP instruction, which is defined to be serialization point, and use of which (instead of LFENCE; RDTSC sequence) also fixes test, as confirmed by Jim. In fact, I now think that we should also apply the following patch. Otherwise, consequtive calls to e.g. binuptime(9) could return decreased time stamps. Note that libc __vdso_gettc.c already has LFENCE nearby the tsc reads, which was done not for this reason, but apparently needed for the reason too. diff --git a/sys/x86/x86/tsc.c b/sys/x86/x86/tsc.c index 085c339..229b351 100644 --- a/sys/x86/x86/tsc.c +++ b/sys/x86/x86/tsc.c @@ -594,6 +594,7 @@ static u_int tsc_get_timecount(struct timecounter *tc __unused) { =20 + rmb(); return (rdtsc32()); } =20 @@ -602,8 +603,9 @@ tsc_get_timecount_low(struct timecounter *tc) { uint32_t rv; =20 + rmb(); __asm __volatile("rdtsc; shrd %%cl, %%edx, %0" - : "=3Da" (rv) : "c" ((int)(intptr_t)tc->tc_priv) : "edx"); + : "=3Da" (rv) : "c" ((int)(intptr_t)tc->tc_priv) : "edx"); return (rv); } =20 --1Dj3cEIIrBZAiNOW Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlAPyKkACgkQC3+MBN1Mb4h5lgCfX7aUTYLRIMXAkkPPXxP8nS4Q xmkAn2aZIRz0JMn3SWE6ifZOHUh7ZkHd =ass/ -----END PGP SIGNATURE----- --1Dj3cEIIrBZAiNOW--