From owner-freebsd-current@FreeBSD.ORG Fri Oct 28 17:33:20 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7EC7716A41F; Fri, 28 Oct 2005 17:33:20 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2FD5843D45; Fri, 28 Oct 2005 17:33:20 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 9B89A46B08; Fri, 28 Oct 2005 13:33:19 -0400 (EDT) Date: Fri, 28 Oct 2005 18:33:19 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Chuck Swiger In-Reply-To: <43625ECE.7010804@mac.com> Message-ID: <20051028183034.U3405@fledge.watson.org> References: <32412.1130505646@critter.freebsd.dk> <436229CF.6040001@freebsd.org> <20051028144307.X53858@fledge.watson.org> <43625ECE.7010804@mac.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Poul-Henning Kamp , David Xu , current@freebsd.org Subject: Re: Timers and timing, was: MySQL Performance 6.0rc1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2005 17:33:20 -0000 On Fri, 28 Oct 2005, Chuck Swiger wrote: >> I'm happy to take a stab at this. >> >> We still need someone to grab the context switch time keeping by the >> horns and Do Something, though. > > If I understand what was said earlier, the getmicrotime() kernel > function ought to maintain the time at "(~ 1 msec)" precision. Could > getmicrotime() be exported as a syscall, so that we could do something > like this: > > --- lib/libc/gen/time.c~ Fri Jul 18 22:53:46 2003 > +++ lib/libc/gen/time.c Fri Oct 28 13:04:26 2005 > @@ -47,7 +47,8 @@ > struct timeval tt; > time_t retval; > > - if (gettimeofday(&tt, (struct timezone *)0) < 0) > + getmicrotime(&tt); > + if (tt.tv_sec == 0) > retval = -1; > else > retval = tt.tv_sec; > > Note that this might even cause time(2) to return an error if the system > is using dummyclock, which could be considered a feature. :-) In the rwatson_clock branch in Perforce, I've added two new clocks to clock_gettime(): CLOCK_SECOND - getnanotime() with nanoseconds truncated CLOCK_FUZZY - getnanotime() without nanoseconds truncated I recognize that both names are badly chosen. I'm compiling kernels to do a bit of benchmarking currently. If we remove the call to nanotime() in the context switch, we may want to add a callout that calls nanotime() once each tick? Or maybe automatically in the callout handler, so that any code running in a callout can use getnanotime() without having to worry about accuracy (much). Robert N M Watson