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
_______________________________________________
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
