From owner-freebsd-current@FreeBSD.ORG Sat Apr 28 11:23:14 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A1BC516A419; Sat, 28 Apr 2007 11:23:14 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 843ED13C4B8; Sat, 28 Apr 2007 11:23:13 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 7EBB947028; Sat, 28 Apr 2007 07:23:12 -0400 (EDT) Date: Sat, 28 Apr 2007 12:23:12 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Hartmut Brandt In-Reply-To: <4633299B.2020206@dlr.de> Message-ID: <20070428121554.T28395@fledge.watson.org> References: <20070423113400.GC28587@gw.humppa.dk> <462CD251.9060105@freebsd.org> <20070423161711.GV39474@elvis.mu.org> <462D821F.6030707@freebsd.org> <20070424042102.GI38475@tnn.dglawrence.com> <86veflholn.fsf@dwp.des.no> <20070428113752.A28395@fledge.watson.org> <4633299B.2020206@dlr.de> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-709611121-1177759392=:28395" Cc: current@freebsd.org, =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , Tim Kientzle , David G Lawrence , "Jesper B. Rosenkilde" Subject: Re: Suggestions on Avoiding syscall Overhead 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: Sat, 28 Apr 2007 11:23:14 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-709611121-1177759392=:28395 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Sat, 28 Apr 2007, Hartmut Brandt wrote: > Robert Watson wrote: >>=20 >> On Tue, 24 Apr 2007, Dag-Erling Sm=F8rgrav wrote: >>=20 >>> David G Lawrence writes: >>>> gettimeofday(2) returns microsecond precision, so I don't see how this= =20 >>>> could be made accelerated via a mapped global page. time(3) [which is= =20 >>>> currently a wrapper for gettimeofday(2)], on the other had, could be p= ut=20 >>>> into such a page since it only updates once a second. >>>=20 >>> gettimeofday(2) returns a value in microseconds, but this does not=20 >>> necessarily mean that it has microsecond precision. Updating it once p= er=20 >>> scheduler tick or once per context switch (in userret(), for instance) = is=20 >>> probably enough. >>=20 >> We have an overall issue with the cost vs prevision of time measurement = in=20 >> FreeBSD. We err on the side of precision; other systems err on the side= of=20 >> cost. I'm not sure that gettimeofday() is best optimized in the way you= =20 >> describe, since if we're going to sacrifice precision, we could sacrific= e a=20 >> lot less precision and still get massively better performance. > > Sorry to jump in here with a rather generic comment. It would be nice if = the=20 > user program had a choice on the precision/cost issue. While most of the= =20 > programs really don't care about precision (as long as it is not in the= =20 > second range) there are applications that would rather have more precisio= n=20 > even when it comes with much higher cost. I think there is such a choice = in=20 > the kernel with the microtime()/getmicrotime() stuff. I have, for example= ,=20 > applications that do network performance measurements and rather low=20 > bandwidth satellite connections. I don't care about cost but care about= =20 > precision. So it would be great if the application had a choice. I don't= =20 > know what is the best way to do this - have different system calls, have = a=20 > call that at program start says: give me more precision or give me lesser= =20 > cost. I'm sure you guys find a way. Just make sure that you don't force o= ne=20 > precision/cost tradeoff on everybody. One of the questions that's been tricky in the past is how best to offer th= at=20 choice. The ideal case is that things are fast and precise. If that's not= =20 possible, then presumably we need a source of policy. I think, ideally, th= is=20 is the programmer/application, as that allows the trade-off to be considere= d,=20 and likely configured, in the context of the application. The programmer= =20 knows the difference between time measurements gathered for occasional=20 statistics profiling and timing measurements gathered for the purposes of= =20 precise network mapping or event handling. Unfortunately, this sort of thing can't be expressed using the standard API= s.=20 This leaves us two choices: allow the behavior of standard APIs to be=20 configured at some granularity, or introduce new APIs. My feeling is we=20 should prefer new APIs, and suggest that programmers use those. Take a loo= k=20 at sys/sys/time.h:1.71 for an example of what might make sense. Robert N M Watson Computer Laboratory University of Cambridge --0-709611121-1177759392=:28395--