Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 22 Jan 2004 14:36:57 -0500 (EST)
From:      Robert Watson <rwatson@freebsd.org>
To:        bn@donut.ugcs.caltech.edu
Cc:        current@freebsd.org
Subject:   Re: apparent lock contention
Message-ID:  <Pine.NEB.3.96L.1040122134907.80401H-100000@fledge.watson.org>
In-Reply-To: <20040121191932.GK56512@philemon.caltech.edu>

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1040122134907.80401H-100000>