[OpenAFS-devel] funny lookup/dnlc/dcache/...

[John S. Bucy]

Most of my performance study has ended up looking at the performance
of cache-resident workloads; a number of other folks here have been
looking at the end-to-end performance anyway.

One thing I've been looking at is the performance of directory name
lookups.  I notice that there is a dnlc ("directory name lookup
cache"?) which is statically sized to 300 entries.  There seems to be
some funny interaction between it and the Linux dentry cache.  I'm
doing the following experiment on 2.6.11/1.3.80:

create files 0 to n-1
take a random permutation of the names
loop some number of times:  (100 for these results)
  loop over names i in permutation:
    stat name i

I'm looking at the average amount of time (all in userspace
w/gettimeofday()) taken by the stat().

          ext3    AFS
n=4k       3us   33us
n=16000    3us  720us

I get similar performance if I create 16k files and access e.g. the
first 1000.

It seems like all of the lookups should hit in Linux's dentry cache --
they seem to for ext3 -- but AFS is doing a lot of extra work
somewhere.  Like many of them are missing and its falling back to
afs_dir_Lookup().

I'm running with -stat 16k so all the accesses are vcache resident.
tcpdump output during the experiment is quiet.  iostat shows that
there isn't any other IO going on, either.



Why couldn't Linux dispense with the dnlc and let the dentry cache do
all the work?  

dnlc size should probably be tunable in any event.



john