| From: | Florian Weimer <fw(at)deneb(dot)enyo(dot)de> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: gettimeofday is at the end of its usefulness? |
| Date: | 2017-01-13 20:48:51 |
| Message-ID: | 87wpdy1ya4.fsf@mid.deneb.enyo.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
* Tom Lane:
> Florian Weimer <fw(at)deneb(dot)enyo(dot)de> writes:
>> * Tom Lane:
>>> On Linux (RHEL6, 2.4GHz x86_64), I find that gettimeofday(),
>>> clock_gettime(CLOCK_MONOTONIC), and clock_gettime(CLOCK_REALTIME)
>>> all take about 40ns. Of course gettimeofday() only has 1us resolution,
>>> but the other two have perhaps 10ns resolution (I get no duplicate
>>> readings in a tight loop).
>
>> Isn't this very specific to kernel and glibc versions, depending on
>> things like CONFIG_HZ settings and what level of vDSO support has been
>> backported?
>
> No doubt, but I have yet to find a platform where clock_gettime() exists
> but performs worse than gettimeofday(). Do you know of one?
ppc64le with all the vDSO fixes for clock_gettime?
glibc has some test cases which fail because clock_gettime gives
inconsistent results. This has been fixed in current kernels, but I
don't know if everyone uses them.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2017-01-13 20:54:24 | Re: gettimeofday is at the end of its usefulness? |
| Previous Message | Pavel Stehule | 2017-01-13 20:45:04 | Re: Packages: Again |