Date: Sat, 28 Apr 2007 12:23:12 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Hartmut Brandt <Hartmut.Brandt@dlr.de> Cc: current@freebsd.org, =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= <des@des.no>, Tim Kientzle <kientzle@freebsd.org>, David G Lawrence <dg@dglawrence.com>, "Jesper B. Rosenkilde" <jbr@humppa.dk> Subject: Re: Suggestions on Avoiding syscall Overhead Message-ID: <20070428121554.T28395@fledge.watson.org> In-Reply-To: <4633299B.2020206@dlr.de> References: <f126fae00704221639l68095de1ye7ce9ba3d921bf20@mail.gmail.com> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <dg@dglawrence.com> 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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070428121554.T28395>