Fast gettimeofday(2) and clock_gettime(2)
John Baldwin
jhb at freebsd.org
Wed Jun 6 18:23:54 UTC 2012
On Wednesday, June 06, 2012 12:51:15 pm Konstantin Belousov wrote:
> A positive result from the recent flame-bait on arch@ is the working
> implementation of the fast gettimeofday(2) and clock_gettime(2). The
> speedup I see is around 6-7x on the 2600K. I think the speedup could
> be even bigger on the previous generation of CPUs, where lock
> operations and syscall entry are costlier. A sample test runs of
> tools/tools/syscall_timing are presented at the end of message.
In general this looks good but I see a few nits / races:
1) You don't follow the model of clearing tk_current to 0 while you
are updating the structure that the in-kernel timecounter code
uses. This also means you have to avoid using a tk_current of 0
and that userland has to keep spinning as long as tk_current is 0.
Without this I believe userland can read a partially updated
structure.
2) You read tk->tk_boottime without the tk_current protection in your
non-uptime routines. This is racey as the kernel alters the
boottime when it skews time for large adjustments from ntp, etc.
To be really safe you need to read the boottime inside the loop
into a local variable and perhaps use a boolean parameter to decide
if you should add it to the computed uptime.
> sandy% /usr/home/pooma/build/bsd/DEV/stuff/tests/syscall_timing_32
gettimeofday
> Clock resolution: 0.000000076
> test loop time iterations periteration
> gettimeofday 0 1.000994225 21623297 0.000000046
> gettimeofday 1 1.000994980 21596492 0.000000046
> gettimeofday 2 1.001070595 21598326 0.000000046
> gettimeofday 3 1.000922308 21581398 0.000000046
> gettimeofday 4 1.000984264 21605539 0.000000046
> gettimeofday 5 1.000989697 21601659 0.000000046
> gettimeofday 6 1.000996261 21598385 0.000000046
> gettimeofday 7 1.001002223 21583933 0.000000046
> gettimeofday 8 1.000985847 21599442 0.000000046
> gettimeofday 9 1.000994977 21600935 0.000000046
> sandy% sudo sysctl kern.timecounter.fast_gettime=0
I think this means you can call gettimeofday() in about 46 ns now
vs 310 the "old" way?
--
John Baldwin
More information about the freebsd-arch
mailing list