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?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: [HACKERS] Packages: Again
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] gettimeofday is at the end of its usefulness?