From owner-freebsd-current@FreeBSD.ORG Fri Oct 28 20:15:27 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0CF5916A41F for ; Fri, 28 Oct 2005 20:15:27 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from mail23.syd.optusnet.com.au (mail23.syd.optusnet.com.au [211.29.133.164]) by mx1.FreeBSD.org (Postfix) with ESMTP id CBEF543D72 for ; Fri, 28 Oct 2005 20:15:17 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail23.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id j9SKF8jw006209 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 29 Oct 2005 06:15:14 +1000 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1]) by cirb503493.alcatel.com.au (8.12.10/8.12.10) with ESMTP id j9SKF5Hh053589; Sat, 29 Oct 2005 06:15:08 +1000 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost) by cirb503493.alcatel.com.au (8.12.10/8.12.9/Submit) id j9SKF5GV053588; Sat, 29 Oct 2005 06:15:05 +1000 (EST) (envelope-from pjeremy) Date: Sat, 29 Oct 2005 06:15:05 +1000 From: Peter Jeremy To: Poul-Henning Kamp Message-ID: <20051028201505.GV39882@cirb503493.alcatel.com.au> References: <20051028093402.GT39882@cirb503493.alcatel.com.au> <30571.1130493159@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30571.1130493159@critter.freebsd.dk> User-Agent: Mutt/1.4.2.1i X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc Cc: current@freebsd.org Subject: Re: Timers and timing, was: MySQL Performance 6.0rc1 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: Fri, 28 Oct 2005 20:15:27 -0000 On Fri, 2005-Oct-28 11:52:39 +0200, Poul-Henning Kamp wrote: >In message <20051028093402.GT39882@cirb503493.alcatel.com.au>, Peter Jeremy wri >>FreeBSD already supports a variety of different timecounters with >>different levels of accuracy/performance/guarantees. One problem is >>that this is a system-wide knob whereas different applications may >>have different requirements. > >We _really_ don't want different programs using different hardware >for timecounting, so I hope you're just taking about the various >levels of quality supported (ie: [get]{bin,nano,micro}[up]time()) I was thinking that if the cost differential is large enough, it might be worthwhile using different hardware counters (especially for duration values where you don't have to worry about getting a valid UTC time). This would probably mean adding a system call to set a default timer type which is part of the struct proc - upon reflection, there would be a significant amount of kernel API churn (at least) to get this to work. To go off on a different tangent, would it be possible to use the NTP algorithms to synchronize the TSC? If the TSC's all tick together (which may be true on i386 but I believe isn't on Alpha) then all you need is a relative offset, otherwise you need a rate multiplier as well. Have one kthread per CPU to manage the local TSC and (ideally) publish the offset and ratio on a per-CPU magic data page that everyone is discussing elsewhere in this thread. This gives something like: now = magic->offset + (rdtsc() * magic->multiplier) >> magic->shift; (though the (x*y)>>z would need to be implemented more carefully to avoid truncation in the multiplication). [The SunOS 4.x approach was something like 0xFFFFn000 was the page for CPU n (or maybe n/2 - I can't remember whether they were 4K or 8K pages) and 0xFFFFE000 was the page for the CPU you were executing on.] -- Peter Jeremy