On Fri, 2 Jan 2015 18:15:06 -0500 grarpamp <grarpamp@xxxxxxxxx> wrote: > On Fri, Jan 2, 2015 at 12:24 PM, Konstantin Belousov > <kostikbel@xxxxxxxxx> wrote: > > On Fri, Jan 02, 2015 at 09:09:34AM -0500, grarpamp wrote: > >> Some recent FreeBSD related questions in this app area. > >> > > What is the question ? > > > > As a background, I can repeat that FreeBSD implements syscall-less > > gettimeofday() and clock_gettime() for x86 machines which have > > usable RDTSC. The selection of the timecounter can be verified > > by sysctl kern.timecounter.hardware, and enabled by default fast > > gettimeofday(2) can be checked by sysctl > > kern.timecounter.fast_gettime. > > > > On some Nehalem machine, I see it doing ~30M calls/sec with enabled > > fast_gettime, and ~6.25M calls/sec with disabled fast_gettime. This > > is measured on 2.8GHz Core i7 930 with > > src/tools/tools/syscall_timing. > > > > Check your timecounter hardware. Since it was noted that the tests > > were done in VM, check the quality of RDTSC emulation in your > > hypervisor. This all is kind of a moot point because even if the relevant time calls did take ~2 usec it still doesn't explain the performance issues, and my curiosity is close to being exhausted. But, for what it's worth. Forcing the timecounter hardware source to "TSC" in my VM results in a saner value (~45 ns). That said, I'm not sure if the clock source is actually sane. A quick skim through the code suggests that there's a decent number of things that would keep the TSC from being used, though VirtualBox supports the P-state invariant TSC cpuid bit (Linux picks it up), so why I'm seeing this behavior eludes me. Curiosity exhausted at this point, -- Yawning Angel
Attachment:
pgpNCpAojAPrL.pgp
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev