Re: Use CLOCK_MONOTONIC_COARSE for instr_time when available

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

In response to

Browse pgsql-hackers by date

  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