cvs commit: src/sys/sys time.h src/sys/kern kern_time.c
bde at zeta.org.au
Sun Nov 27 12:45:36 GMT 2005
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
> 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
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
> 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.)
More information about the cvs-src