Date: Sat, 28 Apr 2007 22:11:32 +0200 From: Hartmut Brandt <Hartmut.Brandt@dlr.de> To: Robert Watson <rwatson@FreeBSD.org> 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: <4633AA74.40807@dlr.de> In-Reply-To: <20070428121554.T28395@fledge.watson.org> 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> <20070428121554.T28395@fledge.watson.org>
index | next in thread | previous in thread | raw e-mail
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 <dg@dglawrence.com> 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... hartihelp
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4633AA74.40807>