From owner-freebsd-arch@FreeBSD.ORG Fri Jun 8 08:39:33 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 D41A1106564A; Fri, 8 Jun 2012 08:39:33 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail07.syd.optusnet.com.au (mail07.syd.optusnet.com.au [211.29.132.188]) by mx1.freebsd.org (Postfix) with ESMTP id 66C748FC0A; Fri, 8 Jun 2012 08:39:33 +0000 (UTC) Received: from c122-106-171-232.carlnfd1.nsw.optusnet.com.au (c122-106-171-232.carlnfd1.nsw.optusnet.com.au [122.106.171.232]) by mail07.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q588dUPu023160 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Jun 2012 18:39:31 +1000 Date: Fri, 8 Jun 2012 18:39:30 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: John Baldwin In-Reply-To: <201206070810.08166.jhb@freebsd.org> Message-ID: <20120608180723.S1641@besplex.bde.org> References: <20120606165115.GQ85127@deviant.kiev.zoral.com.ua> <201206061423.53179.jhb@freebsd.org> <20120607084229.C1474@besplex.bde.org> <201206070810.08166.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Konstantin Belousov , freebsd-arch@freebsd.org 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: Fri, 08 Jun 2012 08:39:33 -0000 On Thu, 7 Jun 2012, John Baldwin wrote: > On Wednesday, June 06, 2012 9:35:49 pm Bruce Evans wrote: >> On Wed, 6 Jun 2012, John Baldwin wrote: >>> 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). Without the timehands array you will need slow atomic ops or maybe MD magic to make them unnecessary. I think 3 generations are necessary and sufficient: one pointed to by timehands for normal use; another that used to be pointed to be timehands and that remains valid for 1 more generation time after timehands was switched away from it, and one invalid/unready/being_updated one that will become the one pointed to by timehands 1 generation after it was updated. 2 generations are needed instead of 1 to allow updating one while the other remains usable, and 3 generations are needed instead of 1 to ensure that the one pointed to by timehands remains valid for a full generation time (average 1.5 generation times) after any read of timehands. Bruce