Date: Mon, 1 Apr 2002 19:03:47 +0200 From: Eivind Eklund <eivind@FreeBSD.ORG> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: Dag-Erling Smorgrav <des@ofug.org>, "Andrew R. Reiter" <arr@FreeBSD.ORG>, "Greg 'groggy' Lehey" <grog@FreeBSD.ORG>, arch@FreeBSD.ORG Subject: Re: mutex profiling Message-ID: <20020401190347.B17023@phoenix.dmnshq.net> In-Reply-To: <18325.1017679644@critter.freebsd.dk>; from phk@critter.freebsd.dk on Mon, Apr 01, 2002 at 06:47:24PM %2B0200 References: <20020401184158.A15491@phoenix.dmnshq.net> <18325.1017679644@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Apr 01, 2002 at 06:47:24PM +0200, Poul-Henning Kamp wrote: > In message <20020401184158.A15491@phoenix.dmnshq.net>, Eivind Eklund writes: > >The use of filename/line combinations was done to be able to find what actual > >lock aquisitions result in introduction of large amounts of latency. The > >basic reason I wrote this patch was to be able to find what parts of our code > >result in latency, to focus effort there. > > > >Measuring the lock types themselves (which is what the lock description would > >give you) give a much less granular set of information. This accumulation can > >(non-trivially) be done separately, but if you do the accumulation, it is not > >possible to recover the information about where the latency is introduced. > > I think you misunderstood, I think the request was to get the lock > name in addition to the file/line info. My intent was just to give the background for the choice, as DES is the one presently working on the patch. Apart from that, it would probably be useful to be able to aquire statisticks for locks based on either of those keys. The filename/line combination gives single lock aquisitions, and show where we get latency from that, and thus which code paths would give us the largest amount of latency reduction by being shortened (or broken by a lock release/reaquire, the way to Linux low latency patches do it). I suspect statistics based on lock types (descriptions) will give us ideas of what introduce overall system latency and for what types of locks we should be doing more work to optimize overall throughput. Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020401190347.B17023>