Date: Wed, 10 May 2006 10:42:39 +0200 From: Suleiman Souhlal <ssouhlal@FreeBSD.org> To: Paul Allen <pallen@ugcs.caltech.edu> Cc: freebsd-performance@freebsd.org, current@freebsd.org Subject: Re: Fine-grained locking for POSIX local sockets (UNIX domain sockets) Message-ID: <4461A77F.5080508@FreeBSD.org> In-Reply-To: <20060509183127.GD17515@retch.ugcs.caltech.edu> References: <20060506150622.C17611@fledge.watson.org> <200605090335.00451.hadara@bsd.ee> <20060509004203.GA55852@xor.obsecurity.org> <200605091818.12676.hadara@bsd.ee> <4460D2CA.5090808@elischer.org> <20060509183127.GD17515@retch.ugcs.caltech.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Paul Allen wrote: >>From Julian Elischer <julian@elischer.org>, Tue, May 09, 2006 at 10:35:06AM -0700: > >>Sven Petai wrote: >> >>are there any patches that take the gettimeofday() calls and replace >>them with something that is cheap >>such as only doing every 10th one and just returning the last value ++ 1 >>uSec for the other ones.. > > Better yet, just realize that during any given scheduler quantum the process > is running on the same CPU. Therefore, you should just read the TSC. > > For that matter, if libc would just remember an accurate synchronized > timestamp and TSC pair on a per CPU basis, it should be trivial to get > cheap, synchronized, and accurate TSC time on SMP systems. TSC drift > isn't horrible--and best of all if the process drifts from CPU to CPU > libc will have a decent chance at doing incremental calibrations. Simply > giving libc easy access to a counter of scheduler ticks can be used to > ensure this process delivers monotonic time. > > Let me formalize this a bit, you have a noisy, but cheap time source: > the TSC always available provided you compute your deltas a per cpu basis. > You have another low resolution, low noise, but cheap time source: the > count of scheduler ticks. Rather than coding an ad hoc algorithm, > this information should be fed into a kalman filter. > > There are some lingering details: you need to invalidate the > TSC when the processor speed changes: but this is controlled > by powerd no? Second, if you can manage to throttle the CPU > it suggests that you can also manage to pay higher time > query costs and force clock_gettime calls. That's not enough. On some CPUs (like the current Opterons), the TSC slows down when the CPU executes a HLT instruction, so if you want good accuracy, you'll need to take that into account too. -- Suleiman
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4461A77F.5080508>