From owner-freebsd-arch@FreeBSD.ORG Wed Jun 6 18:23:54 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B0E701065672 for ; Wed, 6 Jun 2012 18:23:54 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 86DD38FC14 for ; Wed, 6 Jun 2012 18:23:54 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id EC55EB918; Wed, 6 Jun 2012 14:23:53 -0400 (EDT) From: John Baldwin To: freebsd-arch@freebsd.org Date: Wed, 6 Jun 2012 14:23:53 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p13; KDE/4.5.5; amd64; ; ) References: <20120606165115.GQ85127@deviant.kiev.zoral.com.ua> In-Reply-To: <20120606165115.GQ85127@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201206061423.53179.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 06 Jun 2012 14:23:54 -0400 (EDT) Cc: Konstantin Belousov Subject: Re: Fast gettimeofday(2) and clock_gettime(2) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 18:23:54 -0000 On Wednesday, June 06, 2012 12:51:15 pm Konstantin Belousov wrote: > A positive result from the recent flame-bait on arch@ is the working > implementation of the fast gettimeofday(2) and clock_gettime(2). The > speedup I see is around 6-7x on the 2600K. I think the speedup could > be even bigger on the previous generation of CPUs, where lock > operations and syscall entry are costlier. A sample test runs of > tools/tools/syscall_timing are presented at the end of message. In general this looks good but I see a few nits / races: 1) You don't follow the model of clearing tk_current to 0 while you are updating the structure that the in-kernel timecounter code uses. This also means you have to avoid using a tk_current of 0 and that userland has to keep spinning as long as tk_current is 0. Without this I believe userland can read a partially updated structure. 2) You read tk->tk_boottime without the tk_current protection in your non-uptime routines. This is racey as the kernel alters the boottime when it skews time for large adjustments from ntp, etc. To be really safe you need to read the boottime inside the loop into a local variable and perhaps use a boolean parameter to decide if you should add it to the computed uptime. > sandy% /usr/home/pooma/build/bsd/DEV/stuff/tests/syscall_timing_32 gettimeofday > Clock resolution: 0.000000076 > test loop time iterations periteration > gettimeofday 0 1.000994225 21623297 0.000000046 > gettimeofday 1 1.000994980 21596492 0.000000046 > gettimeofday 2 1.001070595 21598326 0.000000046 > gettimeofday 3 1.000922308 21581398 0.000000046 > gettimeofday 4 1.000984264 21605539 0.000000046 > gettimeofday 5 1.000989697 21601659 0.000000046 > gettimeofday 6 1.000996261 21598385 0.000000046 > gettimeofday 7 1.001002223 21583933 0.000000046 > gettimeofday 8 1.000985847 21599442 0.000000046 > gettimeofday 9 1.000994977 21600935 0.000000046 > sandy% sudo sysctl kern.timecounter.fast_gettime=0 I think this means you can call gettimeofday() in about 46 ns now vs 310 the "old" way? -- John Baldwin