From owner-freebsd-current@FreeBSD.ORG Fri Oct 28 09:52:41 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 AB02D16A41F for ; Fri, 28 Oct 2005 09:52:41 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C03A43D46 for ; Fri, 28 Oct 2005 09:52:41 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id A9862BC84; Fri, 28 Oct 2005 09:52:39 +0000 (UTC) To: Peter Jeremy From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 28 Oct 2005 19:34:02 +1000." <20051028093402.GT39882@cirb503493.alcatel.com.au> Date: Fri, 28 Oct 2005 11:52:39 +0200 Message-ID: <30571.1130493159@critter.freebsd.dk> Sender: phk@critter.freebsd.dk 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 09:52:41 -0000 In message <20051028093402.GT39882@cirb503493.alcatel.com.au>, Peter Jeremy wri tes: >On Fri, 2005-Oct-28 00:35:24 +0200, Poul-Henning Kamp wrote: >> * Does threads have to return ordered timestamps ? >> >> Consider: >> >> CPU1 CPU2 >> >> gettimeofday(t1) >> gettimeofday(t2) >> gettimeofday(t3) >... >> >> [t1 <= t2 <= t3] > >If this reflects kernel threads, unless there's some sort of explicit >synchronization between the two threads, there's no need to guarantee >anything better than t1 <[=] t3. If the threads are explicitly >synchronised, then we should guarantee t1 <= t2 <= t3. Congratulations on spotting the synchronisation issue, you were the first to do so :-) You are also right that we will need to talk about both kernel and userland threads, we may want to give different levels of service. But let me cut to the point, and show the potential for deceptive optimization here: We _could_ decide to make the level of service depend on the usage of explicit synchronization. But to exploit that, we should have to put timekeeping hinting into all explicit synchronization primitives. Again, our microbenchmarks might benefit at the cost of overall system performance. >SunOS 4.x (I'm not sure about SunOS 5.x) did this as well. As Poul >pointed out, this is much easier with sane hardware. The frustrating thing is that sane hardware is so simple to implement. To have gotten it wrong so many times in so many ways can only indicate that there are some really creative people in the WinTel Marchitecture department >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()) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.