From owner-svn-src-all@FreeBSD.ORG Wed Jul 25 19:23:55 2012 Return-Path: <owner-svn-src-all@FreeBSD.ORG> Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 56A0110656A9; Wed, 25 Jul 2012 19:23:55 +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 BC34F8FC23; Wed, 25 Jul 2012 19:23:54 +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 q6PJO4EY068724; Wed, 25 Jul 2012 22:24:04 +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 q6PJNpTQ090861; Wed, 25 Jul 2012 22:23:51 +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 q6PJNpWH090860; Wed, 25 Jul 2012 22:23:51 +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 22:23:51 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Jim Harris <jim.harris@gmail.com> Message-ID: <20120725192351.GR2676@deviant.kiev.zoral.com.ua> References: <201207242210.q6OMACqV079603@svn.freebsd.org> <500F9E22.4080608@FreeBSD.org> <20120725102130.GH2676@deviant.kiev.zoral.com.ua> <20120725233033.N5406@besplex.bde.org> <20120725173212.GN2676@deviant.kiev.zoral.com.ua> <CAJP=Hc9Ys6uou2wfcO=r9D+AaC34mVeHOK1bgFWtBz8kfvWo6A@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DPQvABvJ16HvCXZu" Content-Disposition: inline In-Reply-To: <CAJP=Hc9Ys6uou2wfcO=r9D+AaC34mVeHOK1bgFWtBz8kfvWo6A@mail.gmail.com> 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, Andriy Gapon <avg@freebsd.org>, Bruce Evans <brde@optusnet.com.au> Subject: Re: svn commit: r238755 - head/sys/x86/x86 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" \)" <svn-src-all.freebsd.org> List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/svn-src-all>, <mailto:svn-src-all-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/svn-src-all> List-Post: <mailto:svn-src-all@freebsd.org> List-Help: <mailto:svn-src-all-request@freebsd.org?subject=help> List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/svn-src-all>, <mailto:svn-src-all-request@freebsd.org?subject=subscribe> X-List-Received-Date: Wed, 25 Jul 2012 19:23:55 -0000 --DPQvABvJ16HvCXZu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 25, 2012 at 11:00:41AM -0700, Jim Harris wrote: > On Wed, Jul 25, 2012 at 10:32 AM, Konstantin Belousov > <kostikbel@gmail.com> wrote: > > I also asked Jim to test whether the cause the TSC sync test failure > > is the lack of synchronization between gathering data and tasting it, > > but ut appeared that the reason is genuine timecounter value going > > backward. >=20 > I wonder if instead of timecounter going backward, that TSC test > fails because CPU speculatively performs rdtsc instruction in relation > to waiter checks in smp_rendezvous_action. Or maybe we are saying > the same thing. Ok, the definition of the 'timecounter goes back', as I understand it: you have two events A and B in two threads, provable ordered, say, A is a lock release and B is the same lock acquisition. Assume that you take rdtsc values tA and tB under the scope of the lock right before A and right after B. Then it should be impossible to have tA > tB. I do not think that we can ever observe tA > tB if both threads are executing on the same CPU. --DPQvABvJ16HvCXZu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlAQR8cACgkQC3+MBN1Mb4j+dQCgp7HrGcliuvwV1trGrXhrkND8 u7wAnRrJEgINxLU1l1fGSA5HB5F2LXpr =jvTV -----END PGP SIGNATURE----- --DPQvABvJ16HvCXZu--