On 28 January 2011 16:25, Dan Nelson <dnel...@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 lots
> of possible contention points. procstat -ka and/or dtrace might help you
> determine exactly where.
I'm new with dtrace so I tried this:
lockstat:::rw-block
{
@traces[stack()] = 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()).
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
