cvs commit: src/sys/sys time.h src/sys/kern kern_time.c

[Bruce Evans]

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