Namecache lock contention?

[Ivan Voras]

On 28 January 2011 23:37, Gleb Kurtsou <gleb.kurtsou at gmail.com> wrote:

>> * The dtrace output I've send is from around thirty seconds of
>> operation, so around 2000 PHP runs. (PHP in this case is FastCGI, so
>> the processes are persistent instead of constantly respawning). In
>> these 2000 runs there have been around 20,000 rw-block events in
>> cache_lookup - which is strange.

> Are there rename, rmdir calls? - these purge namecache.
> If cache is empty, VOP_LOOKUP acquires write lock to populate the cache.

No, only creates and deletes on files, no directory operations at all.

>> * Here's another dtrace output without rwlock mutex inlining, showing
>> a different picture than what I've earlier thought: most rw-blocks
>> events are in wlock! http://ivoras.net/stuff/rw-block-noinline.txt  --
>> there are also some blocks without a rwlock function in the trace; I
>> don't understand how rwlock inlining is implemented, maybe the readers
>> are always inlined?
> Add options RWLOCK_NOINLINE, recompiling with -O0 might also be good
> idea.

That's what I meant by "without rwlock mutex inlining". The default
-O2 is enough - aggressive inlining only begins at -O3.