Re: Suggestions on Avoiding syscall Overhead

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_at_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.

Robert N M Watson
Computer Laboratory
University of Cambridge