From: | Peter Geoghegan <pg(at)heroku(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: gettimeofday is at the end of its usefulness? |
Date: | 2014-05-13 23:33:32 |
Message-ID: | CAM3SWZSyLqKgr-TCga=3kdhYhdW5FnMAcbVLVAsgYyrDwDOC0Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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? 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
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/
I can see a benefit in exposing this trade-off to Postgres code
directly. I still think that a correlated reference period will prove
useful, and while there are a number of ways to amortize the cost of
repeatedly (coarsely) getting the wall time in the ordinary course of
choosing victim buffers, it would be nice to do this too.
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2014-05-14 00:16:29 | Re: gettimeofday is at the end of its usefulness? |
Previous Message | Craig Ringer | 2014-05-13 23:23:35 | Re: SKIP LOCKED DATA (work in progress) |