Timers and timing, was: MySQL Performance 6.0rc1
Robert Watson
rwatson at FreeBSD.org
Fri Oct 28 10:33:20 PDT 2005
On Fri, 28 Oct 2005, Chuck Swiger wrote:
>> I'm happy to take a stab at this.
>>
>> We still need someone to grab the context switch time keeping by the
>> horns and Do Something, though.
>
> If I understand what was said earlier, the getmicrotime() kernel
> function ought to maintain the time at "(~ 1 msec)" precision. Could
> getmicrotime() be exported as a syscall, so that we could do something
> like this:
>
> --- lib/libc/gen/time.c~ Fri Jul 18 22:53:46 2003
> +++ lib/libc/gen/time.c Fri Oct 28 13:04:26 2005
> @@ -47,7 +47,8 @@
> struct timeval tt;
> time_t retval;
>
> - if (gettimeofday(&tt, (struct timezone *)0) < 0)
> + getmicrotime(&tt);
> + if (tt.tv_sec == 0)
> retval = -1;
> else
> retval = tt.tv_sec;
>
> Note that this might even cause time(2) to return an error if the system
> is using dummyclock, which could be considered a feature. :-)
In the rwatson_clock branch in Perforce, I've added two new clocks to
clock_gettime():
CLOCK_SECOND - getnanotime() with nanoseconds truncated
CLOCK_FUZZY - getnanotime() without nanoseconds truncated
I recognize that both names are badly chosen. I'm compiling kernels to do
a bit of benchmarking currently.
If we remove the call to nanotime() in the context switch, we may want to
add a callout that calls nanotime() once each tick? Or maybe
automatically in the callout handler, so that any code running in a
callout can use getnanotime() without having to worry about accuracy
(much).
Robert N M Watson
More information about the freebsd-current
mailing list