Date: Wed, 10 May 2006 04:18:53 +0300 From: Sven Petai <hadara@bsd.ee> To: freebsd-performance@freebsd.org Cc: Kris Kennaway <kris@obsecurity.org>, David Xu <davidxu@freebsd.org>, Julian Elischer <julian@elischer.org>, current@freebsd.org Subject: Re: Fine-grained locking for POSIX local sockets (UNIX domain sockets ) Message-ID: <200605100418.54475.hadara@bsd.ee> In-Reply-To: <4460D2CA.5090808@elischer.org> References: <20060506150622.C17611@fledge.watson.org> <200605091818.12676.hadara@bsd.ee> <4460D2CA.5090808@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday 09 May 2006 20:35, Julian Elischer wrote: > 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.. > > a ktrace of Mysql shows a LOT of gettimeofday() calls. > well I have actually done that although in a very hackish way that is suitable *only* for benchmarking, but my goal really was just to find out if gettimeofday really is the bottleneck. Basically I just preloaded my version of "buffering" time() over libc's. That function asked kernel for time only after every 5000 invocations. I could get away with that for benchmarking since about 99,99% of gettimeofday() calls from mysqld really come through time() which has anyway only 1 second resolution and mysqld seems to use the value for purposes that are not really all that critical, like stats and safeguard timers. It's also called far more than 5000 times in a second while benchmark is running so it should return correct values too. Anyway, the results really astonished me, what I got for reducing gettimeofday() calls by ~96% was performance *decrease* of about 4-5%. I thought something was wrong with my measurement techniques, so I wrote the buffering time() function that used TSC directly into mysqld, replaced all the time() calls with that, so that number of gettimeofday() syscalls ktrace reported was down to only the initial one, but still got the same 5% decrease. I just can't explain it, but can't find any mistakes in methods too. The library I used is available @ http://bsd.ee/~hadara/debug/mysql4/time_lib_hack.c
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200605100418.54475.hadara>