Micro-benchmark for various time syscalls...

Gary Stanley gary at velocity-servers.net
Mon Jun 2 19:51:25 UTC 2008

At 06:55 AM 6/2/2008, Bruce Evans wrote:
>On Mon, 2 Jun 2008, Gary Stanley wrote:
>>At 12:54 AM 6/2/2008, Sean Chittenden wrote:
>>>PS  Is there a reason that time(3) can't be implemented in terms of
>>>clock_gettime(CLOCK_SECOND)?  10ms seems precise enough compared to
>>>time_t's whole second resolution.
>>Another interesting idea is to map gettimeofday() to userland, sort 
>>of like darwin (commpage) and linux (vsyscall) via read only page.
>time() can reasonably be implemented like that, but not gettimeofday().
>gettimeofday() should have an accuracy of 1 usec and it returns a large
>data structure that cannot be locked by simple atomic accesses.  The
>read-only page would have to be updated millions of times per second
>or take a pagefault to access to give the same functionality as FreeBSD
>gettimeofday().  The updates would cost about 100% of 1 CPU.  Other
>CPUs could then read the time using locking like that in binuptime()
>but more complicated (needs an atomic update for at least the generation
>count, and probably more).  The pagefaults would give a smaller
>pessimization (I guess slightly longer to reach microtime() than via
>the current syscall, and identical time in microtime() to do the update
>on demand).

Here's a sloppy thought :) What about just rewriting gettimeofday in 
libc to query the TSC and convert it to usecs etc? That would 
eliminate any costly userland -> kernel overhead. I have a proof of 
concept here to do this.

The only bad thing is the skewing of the TSC..

More information about the freebsd-performance mailing list