Re: Suggestions on Avoiding syscall Overhead

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

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