Micro-benchmark for various time syscalls...
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
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