excessive use of gettimeofday(2) and other syscalls

[Peter Jeremy]

On 2011-Sep-06 16:44:48 -0600, Manish Vachharajani <manishv at lineratesystems.com> wrote:
>Under 7.3 (haven't checked 8 or 9) this issue crops up because the
>time system call calls gettimeofday under the hood (see
>lib/libc/gen/time.c).  As a result, the kernel tries to get an
>accurate subsecond resolution time that simply gets chopped to the
>nearest second.

Under 8.x and later, time(3) uses clock_gettime(CLOCK_SECOND,...)
rather than gettimeofday().  This is intended to be much cheaper
than gettimeofday().

On 2011-Sep-06 21:15:55 -0400, Rayson Ho <raysonlogin at gmail.com> wrote:
>IMO, the time returned by gettimeofday does not need to be high
>precision. There are higher resolution time APIs on Linux and I
>believe the application programmers know when to use the slower but
>more accurate clock API.

There are 3 standard APIs for returning time of day:
time(3) provides second precision
gettimeofday(2) provides microsecond precision
clock_gettime(2) provides nanosecond precision

By default, FreeBSD attempts to provide resolution as close as
possible to the precision - which makes the 2 system calls fairly
expensive.  In order to reduce the cost where the resolution isn't
important, FreeBSD provides several non-standard clock types for
clock_gettime(2).  This approach differs from Linux - and it seems
that there is a non-trivial body of code that assumes that calling
gettimeofday() is very cheap.

There is probably a good case for an API that provides a resolution
of the order of a tick but there is no standard for this.

-- 
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20110907/2926227f/attachment.pgp