DragonFly BSD
DragonFly commits List (threaded) for 2013-02
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

git: kernel - Implement shared namecache locks


From: Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxxxxx>
Date: Fri, 22 Feb 2013 22:08:23 -0800 (PST)

commit 79fd1696254e1413ba2bd0b0c029e2acd9ba416a
Author: Matthew Dillon <dillon@apollo.backplane.com>
Date:   Fri Feb 22 21:57:45 2013 -0800

    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.

Summary of changes:
 sys/kern/vfs_cache.c   | 621 +++++++++++++++++++++++++++++++++++++++----------
 sys/kern/vfs_nlookup.c | 112 ++++++---
 sys/sys/namecache.h    |  20 +-
 3 files changed, 588 insertions(+), 165 deletions(-)

http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/79fd1696254e1413ba2bd0b0c029e2acd9ba416a


-- 
DragonFly BSD source repository



[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]