Thomas Munro <thomas.munro@enterprisedb.com> writes:
> On Tue, Dec 27, 2016 at 10:34 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> However, it seems that these impressive results date back only to
>> June 2012, cf
>> https://github.com/freebsd/freebsd/commit/13a9f42818f6b89a72b3e40923be809b490400d8
>> and at least as of that commit, only x86 and x86_64 had the fast
>> clock_gettime code. Older FreeBSD, or FreeBSD on another architecture,
>> is likely to be a lot worse. But I lack an installation to try.
> That commit is in every 'production' and 'legacy' release of
> FreeBSD[1], meaning as far back as 9.3 (expected to be EoL in the next
> few days), because it landed in 9.2 (EoL).
I'm unclear on whether there's any significant number of people running
out-of-support *BSD releases. If it's not something we have to worry
about, fine.
> That leaves the following architectures without
> fast-path time functions:
> macaque:freebsd munro$ git grep 'trivial-vdso_tc.c'
> lib/libc/mips/sys/Makefile.inc:SRCS+= trivial-vdso_tc.c
> lib/libc/powerpc/Makefile.inc:SRCS+= trivial-vdso_tc.c
> lib/libc/powerpc64/Makefile.inc:SRCS+= trivial-vdso_tc.c
> lib/libc/powerpcspe/Makefile.inc:SRCS+= trivial-vdso_tc.c
> lib/libc/riscv/sys/Makefile.inc:SRCS+= trivial-vdso_tc.c
> lib/libc/sparc64/Makefile.inc:SRCS+= trivial-vdso_tc.c
Yeah, I just finished getting results from FreeBSD 10.3 on PPC
(1.33GHz G4 laptop): gettimeofday takes about 1180 ns and clock_gettime
about 1200 ns. That difference seems to be repeatable, but since it's
only 2% I'm not too fussed about it. Interestingly, it's very easy
to tell that it is entering the kernel, because time(1) shows a
significant fraction of system time:
$ time ./testclock
0 bogus readings
100000000 distinct readings 117.96 real 26.80 user 90.31 sys
The same test on platforms with vDSO support shows zero system time.
regards, tom lane
