From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Lukas Fittl <lukas(at)fittl(dot)com> |
Cc: | Jianghua Yang <yjhjstz(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Use CLOCK_MONOTONIC_COARSE for instr_time when available |
Date: | 2025-07-17 00:30:43 |
Message-ID: | afgs3gi3loplgnpta6nsdaemb5i3vox5356zdp2mkorjls7zxq@mp7vop4w5l36 |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2025-07-16 18:24:33 -0400, Tom Lane wrote:
> ... BTW, another resource worth looking at is src/bin/pg_test_timing/
> which we just improved a few days ago [1]. What I see on two different
> Linux-on-Intel boxes is that the loop time that that reports is 16 ns
> and change, and the clock readings appear accurate to full nanosecond
> precision. Changing instr_time.h to use CLOCK_MONOTONIC_COARSE, the
> loop time drops to a bit over 5 ns, which would certainly be a nice
> win if it were cost-free. But the clock precision degrades to 1 ms.
FWIW, switching to using rtscp for timestamp acqusition substantially reduces
timing overhead, albeit not quite as low as 5ns, without loosing any
meaningful precision. The patch from [1] needs to be rebased unfortunately.
Separately, the amount of work we're now doing for each loop iteration in
test_timing() got to start having some effect, no?
Greetings,
Andres
[1] https://postgr.es/m/CAP53PkzO2KpscD-tgFW_V-4WS%2BvkniH4-B00eM-e0bsBF-xUxg%40mail.gmail.com
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Hennessy | 2025-07-17 00:44:25 | simple patch for discussion |
Previous Message | Michael Paquier | 2025-07-17 00:08:15 | Re: Improve error reporting in 027_stream_regress test |