From owner-freebsd-current@FreeBSD.ORG Thu Jan 22 11:39:11 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9B9F616A4CE for ; Thu, 22 Jan 2004 11:39:11 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id DDBD543D45 for ; Thu, 22 Jan 2004 11:39:05 -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 i0MJavUd017330; Thu, 22 Jan 2004 14:36:57 -0500 (EST) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i0MJavW4017327; Thu, 22 Jan 2004 14:36:57 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Thu, 22 Jan 2004 14:36:57 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: bn@donut.ugcs.caltech.edu In-Reply-To: <20040121191932.GK56512@philemon.caltech.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@freebsd.org Subject: Re: apparent lock contention X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2004 19:39:11 -0000 On Wed, 21 Jan 2004 bn@donut.ugcs.caltech.edu wrote: > Under moderate levels of I/O and light processing load, I experience > what appears to be severe contention on Giant with several processes at > a time holding in state "*Giant*" for several seconds each. > > The problem was initiated by a umount operation on a UFS fs which > completed successfully after about ten minutes of whirling. > > This is a SMP system running 5.2-R. > > Can anyone tell me how I might better diagnose what is going on? Well, the first thing to be aware of is that our process monitoring tools all grab Giant when pulling entries out of the kernel. So during the snapshot taking of the kernel, you're guaranteed that *someone* is holding Giant, which increases the chance ot getting contention substantially. Right now we don't have a contention measurement tool, but we've been talking about how best to add one. I think a good start would be simply to add contention counters to the mutex profiling implementation. It wouldn't necessarily indicate the length of contention and average wait times, but it would give a basic measurement of "heat" that would be quite useful. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Senior Research Scientist, McAfee Research