From owner-freebsd-current@FreeBSD.ORG Mon Apr 30 21:42:06 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D9F1C16A401; Mon, 30 Apr 2007 21:42:05 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 8D90E13C44C; Mon, 30 Apr 2007 21:42:05 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 326FE4739D; Mon, 30 Apr 2007 17:42:05 -0400 (EDT) Date: Mon, 30 Apr 2007 22:42:05 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= In-Reply-To: <863b2hpmpn.fsf@dwp.des.no> Message-ID: <20070430224132.R30345@fledge.watson.org> References: <20070423113400.GC28587@gw.humppa.dk> <462CD251.9060105@freebsd.org> <20070423161711.GV39474@elvis.mu.org> <462D821F.6030707@freebsd.org> <20070424042102.GI38475@tnn.dglawrence.com> <86veflholn.fsf@dwp.des.no> <20070428113752.A28395@fledge.watson.org> <4633299B.2020206@dlr.de> <20070428121554.T28395@fledge.watson.org> <86bqh5ppau.fsf@dwp.des.no> <20070430220936.W30345@fledge.watson.org> <863b2hpmpn.fsf@dwp.des.no> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-527998089-1177969325=:30345" Cc: current@freebsd.org, Hartmut Brandt , Tim Kientzle , David G Lawrence , "Jesper B. Rosenkilde" Subject: Re: Suggestions on Avoiding syscall Overhead X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2007 21:42:06 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-527998089-1177969325=:30345 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Mon, 30 Apr 2007, Dag-Erling Sm=F8rgrav wrote: > Robert Watson writes: >> You didn't look at that CVS revision, did you? > > I did, but the relevant changes were lost in the noise of irrelevant Sola= ris=20 > compatibility changes. I've attached the commit message for reference here: ---------------------------- revision 1.71 date: 2005/11/27 00:55:18; author: rwatson; state: Exp; lines: +8 -1 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. 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: New clockid_t name Approximates existing clockid_t CLOCK_REALTIME_FAST CLOCK_REALTIME CLOCK_MONOTONIC_FAST CLOCK_MONOTONIC CLOCK_UPTIME_FAST CLOCK_UPTIME Add one additional new clockid_t, CLOCK_SECOND, which returns the current second without performing a full time counter query or cache lookup overhead to make sure the cached timestamp is stable. This is intended to support very low granularity consumers, such as time(3). The names, visibility, and implementation of the above are subject to change, and will not be MFC'd any time soon. The goal is to expose lower quality time measurement to applications willing to sacrifice accuracy in performance critical paths, such as when taking time stamps for the purpose of rescheduling select() and poll() timeouts. Future changes might include retrofitting the time counter infrastructure to allow the "fast" time query mechanisms to use a different time counter, rather than a cached time counter (i.e., TSC). 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. ---------------------------- Robert N M Watson Computer Laboratory University of Cambridge --0-527998089-1177969325=:30345--