Re: [HACKERS] gettimeofday is at the end of its usefulness?
От | Florian Weimer |
---|---|
Тема | Re: [HACKERS] gettimeofday is at the end of its usefulness? |
Дата | |
Msg-id | 87wpdy1ya4.fsf@mid.deneb.enyo.de обсуждение исходный текст |
Ответ на | Re: [HACKERS] gettimeofday is at the end of its usefulness? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] gettimeofday is at the end of its usefulness?
|
Список | pgsql-hackers |
* Tom Lane: > Florian Weimer <fw@deneb.enyo.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.
В списке pgsql-hackers по дате отправления: