From owner-freebsd-performance@FreeBSD.ORG Tue Jun 3 08:03:14 2008 Return-Path: Delivered-To: freebsd-performance@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F5D41065687 for ; Tue, 3 Jun 2008 08:03:14 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail13.syd.optusnet.com.au (mail13.syd.optusnet.com.au [211.29.132.194]) by mx1.freebsd.org (Postfix) with ESMTP id C7C9F8FC0C for ; Tue, 3 Jun 2008 08:03:13 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c220-239-252-11.carlnfd3.nsw.optusnet.com.au (c220-239-252-11.carlnfd3.nsw.optusnet.com.au [220.239.252.11]) by mail13.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m5382kI2029053 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Jun 2008 18:03:10 +1000 Date: Tue, 3 Jun 2008 18:02:46 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Gary Stanley In-Reply-To: <200806021951.m52JpQEd013447@mail14.syd.optusnet.com.au> Message-ID: <20080603175313.O6038@delplex.bde.org> References: <2B465A44-2578-4675-AA17-EBE17A072017@chittenden.org> <20080602060624.93F5F8FC4A@mx1.freebsd.org> <20080602203217.T3100@delplex.bde.org> <200806021951.m52JpQEd013447@mail14.syd.optusnet.com.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-performance@FreeBSD.org, Bruce Evans Subject: Re: Micro-benchmark for various time syscalls... X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2008 08:03:14 -0000 On Mon, 2 Jun 2008, Gary Stanley wrote: > At 06:55 AM 6/2/2008, Bruce Evans wrote: >> On Mon, 2 Jun 2008, Gary Stanley wrote: >> >>> At 12:54 AM 6/2/2008, Sean Chittenden wrote: >>>> PS Is there a reason that time(3) can't be implemented in terms of >>>> clock_gettime(CLOCK_SECOND)? 10ms seems precise enough compared to >>>> time_t's whole second resolution. >>> >>> Another interesting idea is to map gettimeofday() to userland, sort of >>> like darwin (commpage) and linux (vsyscall) via read only page. >> >> time() can reasonably be implemented like that, but not gettimeofday(). >> gettimeofday() should have an accuracy of 1 usec and it returns a large >> data structure that cannot be locked by simple atomic accesses... > > Here's a sloppy thought :) What about just rewriting gettimeofday in libc to > query the TSC and convert it to usecs etc? That would eliminate any costly > userland -> kernel overhead. I have a proof of concept here to do this. This is hard enough to do in the kernel. The result is the TSC timecounter, which is too hard to make work properly (coherently and without interference from power saving, etc., changing the clock frequency, and on arches that don't have a TSC, and on arches that have a TSC whose access methods are spelled differently than on i386...), except on some machines. > The only bad thing is the skewing of the TSC.. Closer to impossible to handle in userland. Of course, some userland benchmarks that don't need very precise timing can just call rdtsc() and depend on the frequency not changing too much while the benchmark is running. Process times in the kernel use essentially this method.o Another complication with using the TSC is that it executes out of order on many (i386/amd64) CPU types. So rdtsc's inside short sections of code don't work right. Bruce