Suggestions on Avoiding syscall Overhead
Hartmut Brandt
Hartmut.Brandt at dlr.de
Sat Apr 28 20:11:36 UTC 2007
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
More information about the freebsd-current
mailing list