staging/lustre/clio: replace semaphore with mutex
authorDmitry Eremin <dmitry.eremin@intel.com>
Sun, 27 Apr 2014 17:07:00 +0000 (13:07 -0400)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Sun, 27 Apr 2014 17:30:59 +0000 (10:30 -0700)
commit47a57bde2a79cbf5a7fe106d74b8a19531000413
treebf8f52eb4c3aae22f892db8d34a097368e42aaad
parent6246dab1d0d3a91614eb0360e51d9e98b919dbb1
staging/lustre/clio: replace semaphore with mutex

According https://www.kernel.org/doc/Documentation/mutex-design.txt:
- the mutex subsystem is slightly faster and has better scalability
  for contended workloads. In terms of 'ops per CPU cycle', the
  semaphore kernel performed 551 ops/sec per 1% of CPU time used,
  while the mutex kernel performed 3825 ops/sec per 1% of CPU time
  used - it was 6.9 times more efficient.
- there are no fastpath tradeoffs, the mutex fastpath is just as
  tight as the semaphore fastpath. On x86, the locking fastpath is
  2 instructions.
- 'struct mutex' semantics are well-defined and are enforced if
  CONFIG_DEBUG_MUTEXES is turned on. Semaphores on the other hand
  have virtually no debugging code or instrumentation.

One more benefit of mutex is optimistic spinning. It try to spin for
acquisition when there are no pending waiters and the lock owner is
currently running on a (different) CPU. The rationale is that if the
lock owner is running, it is likely to release the lock soon.

This significantly reduce amount of context switches when locked
region is small and we have high contention.
Signed-off-by: Dmitry Eremin <dmitry.eremin@intel.com>
Reviewed-on: http://review.whamcloud.com/9095
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-4257
Reviewed-by: Andreas Dilger <andreas.dilger@intel.com>
Reviewed-by: James Simmons <uja.ornl@gmail.com>
Signed-off-by: Oleg Drokin <oleg.drokin@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drivers/staging/lustre/lustre/llite/llite_internal.h
drivers/staging/lustre/lustre/llite/llite_lib.c