kernel - Implement shared namecache locks
authorMatthew Dillon <dillon@apollo.backplane.com>
Sat, 23 Feb 2013 05:57:45 +0000 (21:57 -0800)
committerMatthew Dillon <dillon@apollo.backplane.com>
Sat, 23 Feb 2013 05:57:45 +0000 (21:57 -0800)
commit79fd1696254e1413ba2bd0b0c029e2acd9ba416a
treef052de022db62ef6c796f4fcca36e8495375774f
parent106d187cc4eaccbbddaab6e02663948653c22dc9
kernel - Implement shared namecache locks

* Currently highly experimental, so I've added a sysctl and default it
  to disabled for now.

  sysctl debug.ncp_shared_lock_disable
0 Shared namecache locks enabled
1 Shared namecache locks disabled (default)

* Removes most conflicts when concurrent processes are doing long path
  lookups with substantially similar prefixes.

* Also removes directory conflicts when concurrent processes are accessing
  different file names under the same directory using short paths.

* Shared mode is only used when the ncp is resolved and in a normal
  working state (this includes entries which have resolved to ENOENT).
  Otherwise the code falls back to exclusive mode.

* Shared namecache locks have three major complexities:

  (1) First, some bits of the nlookup() routine had to be rearranged to
      avoid double locking.  This is because the last namecache component
      always has to be locked exclusively, but a path such as a/b/d/.
      references the same ncp entry for both of the last two components.

  (2) Second, any lock on a namecache structure vhold()'s the related vp
      (if not NULL).  Shared locks present a particular issue where a
      second cpu may obtain a second shared lock before the first cpu
      is able to complete vhold()ing the vnode.  The vnode cannot be
      vhold()'d prior to the lock.  To deal with this an interlock was
      implemented (see NC_SHLOCK_VHOLD).

  (3) Finally, because there might be many concurrent shared lock users
      to avoid starving out an exclusive lock user we must stall further
      shared locks while an exclusive request is pending.

* The implementation specifically does not attempt to implement lock
  upgrading.  That's another can of worms that I'd rather not open.
sys/kern/vfs_cache.c
sys/kern/vfs_nlookup.c
sys/sys/namecache.h