Date: Tue, 3 Jun 2008 18:02:46 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Gary Stanley <gary@velocity-servers.net> Cc: freebsd-performance@FreeBSD.org, Bruce Evans <brde@optusnet.com.au> Subject: Re: Micro-benchmark for various time syscalls... Message-ID: <20080603175313.O6038@delplex.bde.org> In-Reply-To: <200806021951.m52JpQEd013447@mail14.syd.optusnet.com.au> References: <2B465A44-2578-4675-AA17-EBE17A072017@chittenden.org> <20080602060624.93F5F8FC4A@mx1.freebsd.org> <20080602203217.T3100@delplex.bde.org> <200806021951.m52JpQEd013447@mail14.syd.optusnet.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 2 Jun 2008, Gary Stanley wrote: > 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... > > 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. This is hard enough to do in the kernel. The result is the TSC timecounter, which is too hard to make work properly (coherently and without interference from power saving, etc., changing the clock frequency, and on arches that don't have a TSC, and on arches that have a TSC whose access methods are spelled differently than on i386...), except on some machines. > The only bad thing is the skewing of the TSC.. Closer to impossible to handle in userland. Of course, some userland benchmarks that don't need very precise timing can just call rdtsc() and depend on the frequency not changing too much while the benchmark is running. Process times in the kernel use essentially this method.o Another complication with using the TSC is that it executes out of order on many (i386/amd64) CPU types. So rdtsc's inside short sections of code don't work right. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080603175313.O6038>