From owner-freebsd-current@FreeBSD.ORG Sat Apr 28 20:11:36 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 B74C716A400; Sat, 28 Apr 2007 20:11:35 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from smtp-1.dlr.de (smtp-1.dlr.de [195.37.61.185]) by mx1.freebsd.org (Postfix) with ESMTP id 4A76C13C4B0; Sat, 28 Apr 2007 20:11:35 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from [129.247.12.13] ([129.247.12.13]) by smtp-1.dlr.de with Microsoft SMTPSVC(6.0.3790.1830); Sat, 28 Apr 2007 22:11:33 +0200 Message-ID: <4633AA74.40807@dlr.de> Date: Sat, 28 Apr 2007 22:11:32 +0200 From: Hartmut Brandt User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Robert Watson 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> <20070428121554.T28395@fledge.watson.org> In-Reply-To: <20070428121554.T28395@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 28 Apr 2007 20:11:33.0704 (UTC) FILETIME=[6AD7B480:01C789D1] X-Mailman-Approved-At: Sat, 28 Apr 2007 20:27:27 +0000 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 20:11:36 -0000 Robert Watson wrote: > On Sat, 28 Apr 2007, Hartmut Brandt wrote: > >> Robert Watson wrote: >>> >>> On Tue, 24 Apr 2007, Dag-Erling Smørgrav wrote: >>> >>>> David G Lawrence writes: >>>>> gettimeofday(2) returns microsecond precision, so I don't see how >>>>> this could be made accelerated via a mapped global page. time(3) >>>>> [which is currently a wrapper for gettimeofday(2)], on the other >>>>> had, could be put into such a page since it only updates once a >>>>> second. >>>> >>>> gettimeofday(2) returns a value in microseconds, but this does not >>>> necessarily mean that it has microsecond precision. Updating it >>>> once per scheduler tick or once per context switch (in userret(), >>>> for instance) is probably enough. >>> >>> We have an overall issue with the cost vs prevision of time >>> measurement in FreeBSD. We err on the side of precision; other >>> systems err on the side of cost. I'm not sure that gettimeofday() >>> is best optimized in the way you describe, since if we're going to >>> sacrifice precision, we could sacrifice a 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 user program had a choice on the precision/cost issue. While >> most of the programs really don't care about precision (as long as it >> is not in the second range) there are applications that would rather >> have more precision even when it comes with much higher cost. I think >> there is such a choice in the kernel with the >> microtime()/getmicrotime() stuff. I have, for example, applications >> that do network performance measurements and rather low bandwidth >> satellite connections. I don't care about cost but care about >> precision. So it would be great if the application had a choice. I >> don't know what is the best way to do this - have different system >> calls, have a call that at program start says: give me more precision >> or give me lesser cost. I'm sure you guys find a way. Just make sure >> that you don't force one precision/cost tradeoff on everybody. > > One of the questions that's been tricky in the past is how best to > offer that choice. The ideal case is that things are fast and > precise. If that's not possible, then presumably we need a source of > policy. I think, ideally, this is the programmer/application, as that > allows the trade-off to be considered, and likely configured, in the > context of the application. The programmer knows the difference > between time measurements gathered for occasional statistics profiling > and timing measurements gathered for the purposes of precise network > mapping or event handling. > > Unfortunately, this sort of thing can't be expressed using the > standard APIs. This leaves us two choices: allow the behavior of > standard APIs to be configured at some granularity, or introduce new > APIs. My feeling is we should prefer new APIs, and suggest that > programmers use those. Take a look at sys/sys/time.h:1.71 for an > example of what might make sense. I wasn't aware of this stuff. But you're probably right. My feeling is also that new APIs are the way to go... harti