Matt Dillon posted a longer explanation of his namecache work; I’m quoting it here because I’m not knowledgeable enough to summarize.

Quoted text follows:

“Maybe this will help. This is the new namecache structure I am
using:

struct namecache {
LIST_ENTRY(namecache) nc_hash; /* hash chain (parentvp,name) */
TAILQ_ENTRY(namecache) nc_entry; /* scan via nc_parent->nc_list */
TAILQ_ENTRY(namecache) nc_vnode; /* scan via vnode->v_namecache */
TAILQ_HEAD(, namecache) nc_list; /* list of children */
struct namecache *nc_parent; /* namecache entry for parent */
struct vnode *nc_vp; /* vnode representing name or NULL */
int nc_refs; /* ref count prevents deletion */
u_char nc_flag;
u_char nc_nlen; /* The length of the name, 255 max */
char nc_name[0]; /* The segment name (embedded) */
};

And in the vnode:

TAILQ_HEAD(namecache_list, namecache) v_namecache;

What we had before was that the vnode served as the central coordinating
point for the namecache entries, both namecache entries (parent
directories) feeding into the vnode and namecache entries (children in
the directory) going out of the vnode.

What we have above is that the namecache entries now serves as the central
coordinating point and the vnode meerly heads a list of namecache entries
associated with it in particular.

With the new scheme it is possible to maintain completely independant
naming topologies that contain some ‘shared’ vnodes. In the old scheme
you could do that but you would loose track of which naming topology
was used to locate the vnode. In the new scheme the handle IS the
namecache structure and thus the topology used to locate the vnode is
known, even if the vnode is shared amoungst several topologies.

All I have to do, which is what I am working on right now, is change all
the directory references in the codebase from vnodes to namecache pointers.

For example, fd_cdir, fd_rdir, and fd_jdir in sys/filedesc.h need to
be changed from vnode pointers to namecache pointers, and all the VOP_*
functions which take ‘directory vnodes’ as arguments would now instead
take namecache pointers as arguments. namei related functions which take
and return directory vnodes would now have to take and return namecache
pointers. For that matter, these functions would have to take and
return namecache pointers for everything, including file vnodes.

This in turn will allow the lookup functions to gain holds on directories,
files, and non-existant files (placeholders for create, rename) without
having to obtain any vnode locks, which in turn allows us to completely
get rid of the race to root problem as well as other common stalls
associated with blocking I/O during directory lookup operations.”