From owner-freebsd-arch  Mon Apr  1  8:42:45 2002
Delivered-To: freebsd-arch@freebsd.org
Received: from phoenix.dmnshq.net (phoenix.dmnshq.net [194.19.34.94])
	by hub.freebsd.org (Postfix) with SMTP
	id E047037B419; Mon,  1 Apr 2002 08:42:32 -0800 (PST)
Received: (from eivind@localhost)
	by phoenix.dmnshq.net (8.11.6/8.11.6) id g31Gfxd16475;
	Mon, 1 Apr 2002 18:41:59 +0200 (CEST)
	(envelope-from eivind)
Date: Mon, 1 Apr 2002 18:41:58 +0200
From: Eivind Eklund <eivind@FreeBSD.ORG>
To: Dag-Erling Smorgrav <des@ofug.org>
Cc: "Andrew R. Reiter" <arr@FreeBSD.ORG>,
	"Greg 'groggy' Lehey" <grog@FreeBSD.ORG>, arch@FreeBSD.ORG
Subject: Re: mutex profiling
Message-ID: <20020401184158.A15491@phoenix.dmnshq.net>
References: <Pine.NEB.3.96L.1020401112112.11038A-100000@fledge.watson.org> <xzpg02f2xek.fsf@flood.ping.uio.no>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <xzpg02f2xek.fsf@flood.ping.uio.no>; from des@ofug.org on Mon, Apr 01, 2002 at 06:31:31PM +0200
Sender: owner-freebsd-arch@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-arch.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-arch>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-arch>
X-Loop: FreeBSD.ORG

On Mon, Apr 01, 2002 at 06:31:31PM +0200, Dag-Erling Smorgrav wrote:
> "Andrew R. Reiter" <arr@FreeBSD.org> writes:
> > Can we perhaps have the ability to dump the lock char * description?  Or
> > are you doing this way b/c you can get the file and line #'s?  Looks good,
> > tho.
> 
> I can get both; I'm doing it this way because Eivind did it this way
> and it didn't occur to me to change it.  Is one preferrable to the
> other?

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.

Eivind.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message