From owner-freebsd-current@FreeBSD.ORG Wed May 10 08:43:03 2006 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 A677C16A418; Wed, 10 May 2006 08:43:03 +0000 (UTC) (envelope-from ssouhlal@FreeBSD.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3B6FA43D45; Wed, 10 May 2006 08:42:52 +0000 (GMT) (envelope-from ssouhlal@FreeBSD.org) Received: from [137.122.74.158] (host158.thm10.resonet.uottawa.ca [137.122.74.158]) by elvis.mu.org (Postfix) with ESMTP id 4C4431A4D7A; Wed, 10 May 2006 01:42:52 -0700 (PDT) Message-ID: <4461A77F.5080508@FreeBSD.org> Date: Wed, 10 May 2006 10:42:39 +0200 From: Suleiman Souhlal User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051204) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Allen References: <20060506150622.C17611@fledge.watson.org> <200605090335.00451.hadara@bsd.ee> <20060509004203.GA55852@xor.obsecurity.org> <200605091818.12676.hadara@bsd.ee> <4460D2CA.5090808@elischer.org> <20060509183127.GD17515@retch.ugcs.caltech.edu> In-Reply-To: <20060509183127.GD17515@retch.ugcs.caltech.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-performance@freebsd.org, current@freebsd.org Subject: Re: Fine-grained locking for POSIX local sockets (UNIX domain sockets) 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: Wed, 10 May 2006 08:43:04 -0000 Paul Allen wrote: >>From Julian Elischer , Tue, May 09, 2006 at 10:35:06AM -0700: > >>Sven Petai wrote: >> >>are there any patches that take the gettimeofday() calls and replace >>them with something that is cheap >>such as only doing every 10th one and just returning the last value ++ 1 >>uSec for the other ones.. > > Better yet, just realize that during any given scheduler quantum the process > is running on the same CPU. Therefore, you should just read the TSC. > > For that matter, if libc would just remember an accurate synchronized > timestamp and TSC pair on a per CPU basis, it should be trivial to get > cheap, synchronized, and accurate TSC time on SMP systems. TSC drift > isn't horrible--and best of all if the process drifts from CPU to CPU > libc will have a decent chance at doing incremental calibrations. Simply > giving libc easy access to a counter of scheduler ticks can be used to > ensure this process delivers monotonic time. > > Let me formalize this a bit, you have a noisy, but cheap time source: > the TSC always available provided you compute your deltas a per cpu basis. > You have another low resolution, low noise, but cheap time source: the > count of scheduler ticks. Rather than coding an ad hoc algorithm, > this information should be fed into a kalman filter. > > There are some lingering details: you need to invalidate the > TSC when the processor speed changes: but this is controlled > by powerd no? Second, if you can manage to throttle the CPU > it suggests that you can also manage to pay higher time > query costs and force clock_gettime calls. That's not enough. On some CPUs (like the current Opterons), the TSC slows down when the CPU executes a HLT instruction, so if you want good accuracy, you'll need to take that into account too. -- Suleiman