Date: Sun, 27 Nov 2005 23:45:23 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Robert Watson <rwatson@FreeBSD.org> Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/sys time.h src/sys/kern kern_time.c Message-ID: <20051127230412.H28222@delplex.bde.org> In-Reply-To: <200511270055.jAR0tIkF032480@repoman.freebsd.org> References: <200511270055.jAR0tIkF032480@repoman.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 27 Nov 2005, Robert Watson wrote:
> rwatson 2005-11-27 00:55:18 UTC
>
> FreeBSD src repository
>
> Modified files:
> sys/sys time.h
> sys/kern kern_time.c
> Log:
> Add several aliases for existing clockid_t names to indicate that the
> application wishes to request high precision time stamps be returned:
>
> Alias Existing
>
> CLOCK_REALTIME_PRECISE CLOCK_REALTIME
> CLOCK_MONOTONIC_PRECISE CLOCK_MONOTONIC
> CLOCK_UPTIME_PRECISE CLOCK_UPTIME
>
> Add experimental low-precision clockid_t names corresponding to these
> clocks, but implemented using cached timestamps in kernel rather than
> a full time counter query.
These existence of these interfaces is a mistake even in the kernel.
On all machines that I've looked at, the calls to the high-precision
binuptime() outnumber calls to all the other high-level timecounter
routines combined by a large factor. E.g., on pluto1.freebsd.org
(which seems typical) now, after an uptime of ~8 days, there have been
~1200 million calls to binuptime(), ~124 million calls to getmicrouptime(),
~72 million calls to gtemicrotime(), and relatively few other calls.
Thus we get a small speedup at a cost of some complexity and large
inerface bloat.
This is partly because there are too many context switches and context
switches necessarily use a precise timestamp, and file timestamps are
under-represented since they normally use a direct access to time_second.
> This offers a minimum update rate of 1/HZ,
> but in practice will often be more frequent due to the frequency of
> time stamping in the kernel:
Not much more frequent -- see another reply.
> NOTE: With different underlying time mechanisms exposed, using
> different time query mechanisms in the same application may result in
does
> relative non-monoticity or the appearance of clock stalling for a
> single clockid_t, as a cached time stamp queried after a precision
> time stamp lookup may be "before" the time returned by the earlier
> live time counter query.
time(2) cannot be implemented using a low-precision interface for this
reason, at least without fixing the incoherency of these interfaces.
It is a bug for the low-precision interfaces to be incoherent (but see
another mail about the need for explicit synchronization if you need
it; of course, standard interfaces like time(2) need it). I fixed
this bug many years ago in my version for the !SMP case only, but not
very well, but I got tired of this slowing down clock_gettime(2) by
about 8% (much less than in the kernel since syscall overhead dominates
in userland) so I threw out the fix recently. This is another reason
why the imprecise versions shouldn't exist -- it is difficult to fix
them without slowing down the usual case. (My fix consisted of always
syncing using fast UP-specific locking in the usual case.)
Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051127230412.H28222>