From owner-freebsd-current@FreeBSD.ORG Sat Oct 29 04:18:49 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 4FC7C16A41F; Sat, 29 Oct 2005 04:18:49 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id A7CA143D46; Sat, 29 Oct 2005 04:18:48 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id j9T4IL2c066445; Fri, 28 Oct 2005 22:18:21 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 28 Oct 2005 22:18:25 -0600 (MDT) Message-Id: <20051028.221825.90826015.imp@bsdimp.com> To: davidxu@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <4362CBC2.8050602@freebsd.org> References: <35696.1130538037@critter.freebsd.dk> <20051029005719.I20147@fledge.watson.org> <4362CBC2.8050602@freebsd.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Fri, 28 Oct 2005 22:18:22 -0600 (MDT) Cc: pertti.kosunen@pp.nic.fi, phk@phk.freebsd.dk, rwatson@FreeBSD.org, current@FreeBSD.org, jura@networks.ru 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: Sat, 29 Oct 2005 04:18:49 -0000 In message: <4362CBC2.8050602@freebsd.org> David Xu writes: : Robert Watson wrote: : : > Another important question is whether using these alternative time : > access methods in user space improves the performance of any of the : > applications we care about. Hence providing a patch that someone can : > try -- while the microbenchmarks seem to show improved performance, : > will the applications? I suspect it will in some important cases, but : > there's only one way to find out. : > : > It strikes me that replacing time(3) with something that retrieves : > CLOCK_SECOND shouldn't harm time(3) semantics. Likewise, keeping : > CLOCK_REALTIME as is is likely OK -- if an application requests it : > using clock_gettime(), then it is presumably looking for high : > accuracy. It's gettimeofday() that's the troubling one -- it's widely : > used to query the time in applications, and its API suggests : > microsecond resolution. : > : > Robert N M Watson : > : > : thread libraries use clock_gettime, this becauses there is : pthread_cond_timedwait and other synchronization objects : like rwlock, and mutex all have a timeout version, I think : pthread_cond_timedwait is mostly used in some applications, : though normally, application is not looking for high accuracy. : they will get benefit from the clock_gettime speed improvement. And unfortuantely, the argument that needs to be passed to abstime is unspecified, at leas tin our man page. Also unfortuantely, CLOCK_REALTIME seems to be what's required here (our man page just says 'if the system time reaches the time specified in abstime'), rather than CLOCK_MONOTONIC so jumps in system time can cause previously short timeouts to become rather large timeouts... This is a flaw in the API. :-( Warner