Re: gettimeofday is at the end of its usefulness?

Peter Geoghegan <pg(at)heroku(dot)com> writes:
> On Tue, May 13, 2014 at 3:58 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> There's also a CLOCK_REALTIME_COARSE selector, which is noticeably faster
>> --- about 10nsec for me --- but the output appears to only advance once
>> every millisecond, so it's probably useless for our purposes. The other
>> selectors mentioned in the Linux man page are considerably slower than
>> CLOCK_REALTIME for me, suggesting that they actually call into the kernel.

> What Linux kernel version is in use here?

Ah, sorry, I should have specified. This is RHEL6.5, current kernel
version 2.6.32-431.17.1.el6.x86_64.

> Apparently, as I think
> you've stated another way, more recent versions have VDSO for this,
> which can make a big difference. This article seems like a sensible
> guide to all of this:
> https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_MRG/1.3/html/Realtime_Tuning_Guide/sect-Realtime_Tuning_Guide-General_System_Tuning-gettimeofday_speedup.html

This appears to be talking about RHEL5, which is quite a bit older
(and, I'd guess, trailing edge for anybody who might deploy PG 9.5).
I did confirm that /proc/sys/kernel/vsyscall64 exists and has a default
setting of 1 on RHEL6. Setting it to 0 causes gettimeofday to take
150ns, which probably represents the time for a trivial kernel call.
The MRG extension described on the linked page doesn't seem to be
implemented in stock RHEL6 (setting vsyscall64 to 2 is allowed but
doesn't change behavior compared to 1). However, if I'm reading it
right, all that does is make gettimeofday behave like
clock_gettime(CLOCK_REALTIME_COARSE).

> CLOCK_REALTIME_COARSE seemingly influences precision in a way that
> allows user space applications to decide on their precision/cost
> trade-off, rather than being forced to use the system default (that
> procfs surfaces) through gettimeofday():
> http://lwn.net/Articles/342018/

Yeah, I think these are the same implementations exposed to apps in two
different ways, one being a system-wide switch affecting gettimeofday()
while the other allows the app source code to say which one it wants.

regards, tom lane