From owner-freebsd-geom@FreeBSD.ORG Mon Apr 15 18:39:58 2013 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 27851A85; Mon, 15 Apr 2013 18:39:58 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id E825212D1; Mon, 15 Apr 2013 18:39:54 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id 15D891E0; Mon, 15 Apr 2013 20:36:14 +0200 (CEST) Date: Mon, 15 Apr 2013 20:42:03 +0200 From: Pawel Jakub Dawidek To: Alexander Motin Subject: Re: devstat overhead VS precision Message-ID: <20130415184203.GA1839@garage.freebsd.pl> References: <51692C95.3010901@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jRHKVT23PllUwdXP" Content-Disposition: inline In-Reply-To: <51692C95.3010901@FreeBSD.org> X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@FreeBSD.org, freebsd-geom@FreeBSD.org X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 18:39:58 -0000 --jRHKVT23PllUwdXP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Apr 13, 2013 at 12:59:49PM +0300, Alexander Motin wrote: > Hi. >=20 > It is long known that collecting disk and GEOM statistics may cause=20 > significant processing overhead under high IOPS. On my recent high-IOPS= =20 > benchmarks performance difference was reaching three times! Last time=20 > situation improved a lot by more active use of TSC, but there are still= =20 > many systems where TSCs are not synchronized. I propose to switch that=20 > statistics from using binuptime() to getbinuptime() to solve the problem= =20 > globally. >=20 > From one side getbinuptime() resolution is limited by 1ms, but since=20 > time is usually averaged over the many I/Os, additional sub-millisecond= =20 > precision will come from sampling. Since most of tools now show request= =20 > processing times up to 0.1ms, that precision should be sufficient. I=20 > believe real disk performance is more important that n-th digit in some= =20 > statistics. >=20 > The following patch does the change and makes disk performance=20 > irrelevant to the timecounter performance: > http://people.freebsd.org/~mav/devstat_time.patch >=20 > Are there any objections against it? No objections here, but I wonder if you were able to compare the results somehow before and after the change so we have some hard numbers to show that we don't lose much by applying the change. On a mostly unrelated note when two threads (T0 and T1) call get*time() on two different cores, but T0 does that a bit earlier is it possible that T0 can get later time than T1? --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://mobter.com --jRHKVT23PllUwdXP Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlFsSfsACgkQForvXbEpPzSVlgCgtgrIp5Wpi0WYlOFXuCZr8BZY x6IAoOUXv9oinJ61u126VKsqgPeUmWGM =noxd -----END PGP SIGNATURE----- --jRHKVT23PllUwdXP--