From owner-freebsd-current@FreeBSD.ORG Thu Oct 27 22:35:28 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 CA4DF16A41F; Thu, 27 Oct 2005 22:35:28 +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 69E6A43D46; Thu, 27 Oct 2005 22:35:28 +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 B3E82BC7A; Thu, 27 Oct 2005 22:35:24 +0000 (UTC) To: Chuck Swiger From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 27 Oct 2005 16:14:57 EDT." <43613541.7030009@mac.com> Date: Fri, 28 Oct 2005 00:35:24 +0200 Message-ID: <26845.1130452524@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: David Xu , "Yuriy N. Shkandybin" , 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: Thu, 27 Oct 2005 22:35:29 -0000 In message <43613541.7030009@mac.com>, Chuck Swiger writes: >It doesn't make sense to keep invoking a hardware clock from the kernel for a >timer which is updated at a one-second resolution. Can't we just keep a static >time_t called __now in libc for time() to return or stuff into *tloc, which >gets updated once in a while (have the scheduler check whether fractional >seconds has rolled over every few ticks)? That is a quite slippery slope to head down... Calls to time(2) are actually very infrequent (it sort of follows logically from the resolution) and therefore they are unlikely to be a performance concern in any decently thought out code. So adding overhead to the scheduler to improve it is very likely going to be false economy: Yes, performance of the time(2) call will improve but everything else will slow down as a result, even in programs which never inspect a single timestamp. No, this is just the wrong way to attack the problem. What is needed here is for somebody to define how non-perfect we are willing to allow our timekeeping to be, and _THEN_ we can start to look at how fact we can make it work. Here are some questions to start out: For reference the current codes behaviour is noted in [...] * Does time have to be monotonic between CPUs ? Consider: gettimeofday(&t1) // on CPU1 work(x) // a couple context switches gettimeofday(&t2) // on CPU2 Should it be guaranteed that t2 >= t1 ? [Yes] * Does time have to be monotonic between different functions ? Consider (for instance): clock_gettime(&t1) work(x) gettimeofday(&t2) Should it be guaranteed that t2 >= t1 ? For all mixes of time(), gettimeofday() and clock_gettime() ? Or only for funcion pairs in order of increasing resolution ? hint: think about how we round a timespec of 1.000000500 to a timeval. [t2 >= t1 for all mixes, provided comparison is done in format with lowest resolution and conversion is done by truncation] * How large variance (jitter) are we willing to accept ? Consider: gettimeofday(&t1) work(x) /* always constant duration */ gettimeofday(&t2) Twork = timeval_subtract(t2, t1); How much jitter can we live with in Twork ? (ie: how much can Twork vary from run to run of the above code) Is +/- 1 usec required ? Is some constant (but low) +/- N usec OK ? Is +/- 1msec acceptable ? ... +/- 10msec acceptable ? ... +/- 100msec acceptable ? Is 1/hz acceptable ? Also when we don't know which hz the user runs with ? Is Twork == zero OK if work(x) takes more than 500nsec ? [Jitter of +/- 1 count on timecounting hardware] * Does threads have to return ordered timestamps ? Consider: CPU1 CPU2 gettimeofday(t1) gettimeofday(t2) gettimeofday(t3) Do we guarantee that t1 < t2 < t3 or t1 <= t2 <= t3 AND t1 < t3 or t1 <= t2 <= t3 or t1 <= t3 ? [t1 <= t2 <= t3] And when you have answered this, remember that your solution needs to be SMP friendly and work on all architectures. -- 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.