Use CLOCK_MONOTONIC_COARSE in libnative on linux.

[bnoordhuis]

Or CLOCK_MONOTONIC if CLOCK_MONOTONIC_COARSE isn't available but prefer
CLOCK_MONOTONIC_COARSE. The normal monotonic clock is fetched using a
system call but the coarse clock is read directly from the vDSO and
hence is a lot faster.

Make sure it's high-res enough: it normally has a 1 kHz frequency on
systems tuned for interactivity but on systems that are tuned for
throughput, it may run as slow as 100 Hz.

Whether the normal or the coarse clock is used, it should be an
improvement either way. Before, libnative called gettimeofday() and
that polls a clock that is subject to clock skew.

gettimeofday() is still the time source on the other UNIX platforms,
something that will eventually need to be addressed.

[thestinger]

clock_gettime(CLOCK_MONOTONIC) also uses the VDSO, although I think it does a bit more work and there's no reason to not use the coarse one here. Both are actually subject to clock skew (time slowed or sped up) on Linux but will never jump backwards or forwards. The CLOCK_MONOTONIC_RAW function isn't subject to clock skew but skips the VDSO and may run too slow or too fast on hardware where the CPU's timer isn't great (thus, skew).

[alexcrichton]

This is an interesting idea, but sadly I don't think the code will do much as-is. The timer_other.rs file is currently only compiled for osx/freebsd/android, so the code in question won't actually be used (linux uses timer_timerfd.rs).

We do have another "precise timer" in src/libextra/time.rs which is indeed compiled for linux. I personally don't know much about the array of clocks that linux provides, but #11233 may be of interest (lots of discussion over there).

[bnoordhuis]

Ah, sorry about that. I checked for clock_getres() and clock_gettime() calls afterwards with strace but those probably come from somewhere else then.

clock_gettime(CLOCK_MONOTONIC) also uses the VDSO, although I think it does a bit more work and there's no reason to not use the coarse one here.

That's true insofar that clock_gettime(CLOCK_MONOTONIC) starts out as a call to __vdso_clock_gettime() but that function falls back to making a system call when there is no reliable hardware clock to read from (most virtualized systems.)

And as you say, it does more work. It's also very expensive when running a non-paravirt kernel under a hypervisor because the hypervisor traps the rdtsc instruction. Anyway, I suppose that's all academic for now. :-)

[thestinger]

Is the now function just used for relative timers? If that's the only use, then it should certainly use one of the monotonic clocks. I don't know if it should use the coarse clock or the regular one, but it appears that with the current interface it can use the coarse one without a loss.

[thestinger]

(sorry for the noise, I just woke up! :P)

[bnoordhuis]

Is the now function just used for relative timers? If that's the only use, then it should certainly use one of the monotonic clocks.

Yes, agreed. This PR was me working up to a cross-platform solution with some Linux-only performance optimizations thrown in for the sake of it. I'll try to revisit it later this week.