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