On (28/01/2011 18:20), Ivan Voras wrote: > 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()).
You could try replacing rwlock with plain mutex to check if there are priority propagation issues among readers/writers. SX locks should also work but would likely to be a considerable performance regression. Finding out home much activity is there outside of storage/a/b/file (sessions storage) could also be helpful. _______________________________________________ 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"