excessive use of gettimeofday(2) and other syscalls
ambrosehua at gmail.com
Fri Sep 9 13:43:49 UTC 2011
what version of chromium are you using?
I use chromium-13.0.782.215 on amd64 8.2-stable, the gettimeofday call is
far less than 20000 per second, about 20 per second, but I notice old
version has this bug, but latest version has fixed it. Maybe you should
update your chromium and try again.
Firefox 5 and 6 has more gettimeofday call than 20000 per second on my
2011/9/7 Alexander Best <arundel at freebsd.org>
> 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
> i'm running CURRENT on amd64.
> > --
> > Peter Jeremy
> freebsd-hackers at freebsd.org mailing list
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
More information about the freebsd-hackers