Date: Fri, 28 Oct 2005 22:18:25 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: davidxu@FreeBSD.org 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 Message-ID: <20051028.221825.90826015.imp@bsdimp.com> In-Reply-To: <4362CBC2.8050602@freebsd.org> References: <35696.1130538037@critter.freebsd.dk> <20051029005719.I20147@fledge.watson.org> <4362CBC2.8050602@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <4362CBC2.8050602@freebsd.org>
David Xu <davidxu@freebsd.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051028.221825.90826015.imp>