From owner-cvs-all@FreeBSD.ORG Sun Nov 27 12:45:36 2005 Return-Path: X-Original-To: cvs-all@FreeBSD.org Delivered-To: cvs-all@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 589C216A41F; Sun, 27 Nov 2005 12:45:36 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.115]) by mx1.FreeBSD.org (Postfix) with ESMTP id 65A9143D77; Sun, 27 Nov 2005 12:45:27 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.0.87]) by mailout2.pacific.net.au (8.13.4/8.13.4/Debian-3) with ESMTP id jARCjP9X017616; Sun, 27 Nov 2005 23:45:25 +1100 Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy2.pacific.net.au (8.13.4/8.13.4/Debian-3) with ESMTP id jARCjNGN000335; Sun, 27 Nov 2005 23:45:24 +1100 Date: Sun, 27 Nov 2005 23:45:23 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Robert Watson In-Reply-To: <200511270055.jAR0tIkF032480@repoman.freebsd.org> Message-ID: <20051127230412.H28222@delplex.bde.org> References: <200511270055.jAR0tIkF032480@repoman.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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 X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Nov 2005 12:45:36 -0000 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