excessive use of gettimeofday(2) and other syscalls

[Alexander Best]

On Wed Sep  7 11, Peter Jeremy wrote:
> 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.

chromium is triggering ~20.000 gettimeofday(2) calls per second on my machine.
i'm running CURRENT on amd64.

cheers.
alex

> 
> -- 
> Peter Jeremy