Date: Fri, 8 Jun 2012 18:39:30 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: John Baldwin <jhb@freebsd.org> Cc: Konstantin Belousov <kostikbel@gmail.com>, freebsd-arch@freebsd.org Subject: Re: Fast gettimeofday(2) and clock_gettime(2) Message-ID: <20120608180723.S1641@besplex.bde.org> In-Reply-To: <201206070810.08166.jhb@freebsd.org> References: <20120606165115.GQ85127@deviant.kiev.zoral.com.ua> <201206061423.53179.jhb@freebsd.org> <20120607084229.C1474@besplex.bde.org> <201206070810.08166.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120608180723.S1641>