atom feed14 messages in org.freebsd.freebsd-performanceMicro-benchmark for various time sysc...
FromSent OnAttachments
Sean ChittendenJun 2, 2008 5:21 am 
Claus GuttesenJun 2, 2008 8:26 am 
Gary StanleyJun 2, 2008 9:34 am 
Bruce EvansJun 2, 2008 10:55 am 
Bruce EvansJun 2, 2008 11:25 am 
Bruce EvansJun 2, 2008 5:10 pm 
Sean ChittendenJun 2, 2008 7:05 pm 
Sean ChittendenJun 2, 2008 7:11 pm 
Gary StanleyJun 2, 2008 7:58 pm 
Gary StanleyJun 2, 2008 8:24 pm 
Bruce EvansJun 3, 2008 8:02 am 
Bruce EvansJun 3, 2008 9:19 am 
Bruce EvansJun 3, 2008 9:31 am 
Bruce EvansJun 3, 2008 10:14 am 
Subject:Micro-benchmark for various time syscalls...
From:Gary Stanley (ga@velocity-servers.net)
Date:Jun 2, 2008 7:58:24 pm
List:org.freebsd.freebsd-performance

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..