Namecache lock contention?

[Gleb Kurtsou]

On (28/01/2011 18:20), Ivan Voras wrote:
> On 28 January 2011 16:25, Dan Nelson <dnelson at 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.