From owner-cvs-all@FreeBSD.ORG Sat Jan 24 18:07:43 2004 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CDFAD16A4CE; Sat, 24 Jan 2004 18:07:43 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8889143D2F; Sat, 24 Jan 2004 18:07:42 -0800 (PST) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.10/8.12.10) with ESMTP id i0P25XUd068050; Sat, 24 Jan 2004 21:05:33 -0500 (EST) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i0P25Xee068047; Sat, 24 Jan 2004 21:05:33 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Sat, 24 Jan 2004 21:05:33 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org In-Reply-To: <200401250159.i0P1xR4i039361@repoman.freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: cvs commit: src/sys/sys _mutex.h src/sys/kern kern_mutex.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jan 2004 02:07:44 -0000 On Sat, 24 Jan 2004, Robert Watson wrote: > Add some basic support for measuring sleep mutex contention to the > mutex profiling code. As with existing mutex profiling, measurement > is done with respect to mtx_lock() instances in the code, as opposed > to specific mutexes. In particular, measure two things: FYI -- Mutex profiling is pretty neat, and very under-documented. At least, as far as I know, only DES's original commit message and comments in NOTES document it. If someone on the doc side feels moved to explore and document the implementation, as well as provide/gather best practicies for using it in the performance optimization process, that would be great. I.e., mutex_profiling(9) or the like. Now that we're beginning to have significant kernel subsystems running entirely free of Giant, we should be starting to shift gears into more performance analysis and optimization, and documentation is going to be vital for that. Thanks, Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Senior Research Scientist, McAfee Research