Re: [HACKERS] gettimeofday is at the end of its usefulness?

Поиск
Список
Период
Сортировка
От Florian Weimer
Тема Re: [HACKERS] gettimeofday is at the end of its usefulness?
Дата
Msg-id 87y3yyfqqe.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:

> 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).  Other documented clockids include
>     CLOCK_REALTIME_COARSE: about 10ns to read, but only 1ms resolution
>     CLOCK_MONOTONIC_COARSE: about 12ns to read, but only 1ms resolution
>     CLOCK_MONOTONIC_RAW: full resolution but very slow, ~145ns to read
> So CLOCK_MONOTONIC seems to be the thing to use here.  It won't buy
> us anything speed-wise but the extra resolution will be nice.
> However, we need to do more research to see if this holds true on
> other popular distros.

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?



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: [HACKERS] proposal: session server side variables
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: [HACKERS] proposal: session server side variables