Xserver and Gettimeofday

Jesse Barnes jbarnes at virtuousgeek.org
Wed Aug 29 11:00:19 PDT 2007


On Wednesday, August 29, 2007 9:32 am Lukas Hejtmanek wrote:
> On Wed, Aug 29, 2007 at 08:48:15AM -0700, Alan Coopersmith wrote:
> > Xavier Bestel wrote:
> >> That's curious, after having looked at the code it seems the smart
> >> scheduler uses only setitimer, not gettimeofday.
> >> So apparently your problem comes from the driver.
> >
> > GetTimeInMillis in os/utils.c was responsible for most of the
> > gettimeofday() calls I knew of, but it was changed to use
> > clock_gettime instead (on platforms that support it) last year.
>
> I could be something missing, but gettimeofday() actually calls
> clock_gettime syscall similarly to clock_gettime(3).

On Linux at least, gettimeofday calls the gettimeofday syscall, and 
clock_gettime calls the clock_gettime syscall

> In general, there is nothing wrong with gettimeofday or
> clock_gettime, it just must not be called too often (typically when
> waiting in busy loops).

There are actually a few other timing related issues:
  - gettimeofday has a relatively low resolution (usec) vs.
    clock_gettime (nsec) (this isn't really an issue in this case
    though)
  - on some platforms, clock_gettime has a much lower syscall overhead
    than gettimeofday
  - gettimeofday is affected by settimeofday, whereas certain
    clock_gettime clocks are simply monotonic counters

X really wants a low overhead way of getting at a monotonic counter, and 
clock_gettime fits that bill best.  TSCs drift, mapping clocks is 
platform specific, and gettimeofday can change out from under us if the 
user changes the time.  That's not to say X scheduling can't be 
improved, but in the current scheme, clock_gettime seems like the best 
fit.

Jesse



More information about the xorg mailing list