From owner-freebsd-arch@FreeBSD.ORG Thu Jun 7 12:37:51 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 D1C9A106564A for ; Thu, 7 Jun 2012 12:37:51 +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 A68A58FC19 for ; Thu, 7 Jun 2012 12:37:51 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 1CF94B922; Thu, 7 Jun 2012 08:37:51 -0400 (EDT) From: John Baldwin To: freebsd-arch@freebsd.org Date: Thu, 7 Jun 2012 08:10:08 -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> <201206061423.53179.jhb@freebsd.org> <20120607084229.C1474@besplex.bde.org> In-Reply-To: <20120607084229.C1474@besplex.bde.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201206070810.08166.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 07 Jun 2012 08:37:51 -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: Thu, 07 Jun 2012 12:37:51 -0000 On Wednesday, June 06, 2012 9:35:49 pm Bruce Evans wrote: > On Wed, 6 Jun 2012, John Baldwin wrote: > > > 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: > > It is awefully (sic) complete and large. The patch is almost twice as > large as the entire kern_tc.c in FreeBSD-4, and that was quite bloated. > > > 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. > > I thought that too at first, but after looking at the patch decided > that it may be correct, but is too hard for me to understand. > Urk, we both missed that tk_current is an index into the timehands > array, so it cannot act as a generation count and it seems to be harder > to lock. Ugh, so it goes a long way to emulate the timehands array in userland. As I mentioned previously, I consider the timehands array to be a bug. However, I do think the generation count in the in-kernel timehands structure is useful and should be kept (and follow the same model of setting it to 0 before doing updates, then updating the structure, then setting the new generation). -- John Baldwin