kernel - Fix a case in the path lookup that results in high latencies
authorMatthew Dillon <dillon@apollo.backplane.com>
Fri, 7 Jun 2013 22:13:21 +0000 (15:13 -0700)
committerMatthew Dillon <dillon@apollo.backplane.com>
Fri, 7 Jun 2013 22:13:21 +0000 (15:13 -0700)
commit737097c0593fb0012be0369c8ce128934c37b94a
tree0a6b0b393327d912aa3607c83a56314da4e5b781
parentc3d4131842e47b168d93a0650d58d425ebeef789
kernel - Fix a case in the path lookup that results in high latencies

* When many cpu cores are looking up paths with matching components,
  so as when doing a parallel buildworld or a parallel build of
  /usr/src/lib/libc, the namecache's shared/exclusive lock mechanic
  can break-down and create a chain-reaction of exclusive locks which
  destroys performance.

* When attempting to get a shared lock we were previously backing-down to
  an exclusive lock if the shared lock could not be obtained non-blocking.
  The original code could cause a chain-reaction of unnecessary exclusive
  locks.

  Instead, we now only back-down to an exclusive lock only if the current
  thread already holds an exclusive lock on the same namecache entry
  or if we detect that another thread is trying to get an exclusive lock.
  Otherwise we fall-through and obtain the shared lock in a blocking manner.

Reported-by: ftigeot
sys/kern/vfs_cache.c