Date: Fri, 28 Jan 2011 18:20:15 +0100 From: Ivan Voras <ivoras@freebsd.org> To: Dan Nelson <dnelson@allantgroup.com> Cc: freebsd-hackers@freebsd.org Subject: Re: Namecache lock contention? Message-ID: <AANLkTinCbhY5N%2BpuAs9gXT3WOKmPtHCZrb_BwWu__nV6@mail.gmail.com> In-Reply-To: <20110128152505.GP75125@dan.emsphone.com> References: <ihuhav$qso$1@dough.gmane.org> <20110128152505.GP75125@dan.emsphone.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 28 January 2011 16:25, Dan Nelson <dnelson@allantgroup.com> wrote:
> My guess would be:
>
> kern/vfs_cache.c:151 static struct rwlock cache_lock;
> kern/vfs_cache.c:152 RW_SYSINIT(vfscache, &cache_lock, "Name Cache");
>
> The CACHE_*LOCK() macros.c in vfs_cache use cache_lock, so you've got lot=
s
> of possible contention points. =C2=A0procstat -ka and/or dtrace might hel=
p you
> determine exactly where.
I'm new with dtrace so I tried this:
lockstat:::rw-block
{
@traces[stack()] =3D count();
}
with these results:
http://ivoras.net/stuff/rw-block.txt
It's informative because most of the traces are namecache-related. As
suspected, the most blocking occurs in stat().
As this is a rwlock I'd interpret it as waiting for a write lock to be
lifted so the readers can acquire it, but I need to confirm this as
there's a lot of things that can in theory be stat()ed here.
I'm going to continue investigating with dtrace but I'd appreciate
pointers on how to make the output more useful (like including
filenames from stat()).
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTinCbhY5N%2BpuAs9gXT3WOKmPtHCZrb_BwWu__nV6>