Reimplement mutexs for Linux lock profiling/analysis

For a generic explanation of why mutexs needed to be reimplemented
to work with the kernel lock profiling see commits:
  e811949a57 and
  d28db80fd0

The specific changes made to the mutex implemetation are as follows.
The Linux mutex structure is now directly embedded in the kmutex_t.
This allows a kmutex_t to be directly case to a mutex struct and
passed directly to the Linux primative.

Just like with the rwlocks it is critical that these functions be
implemented as '#defines to ensure the location information is
preserved.  The preprocessor can then do a direct replacement of
the Solaris primative with the linux primative.

Just as with the rwlocks we need to track the lock owner.  Here
things get a little more interesting because depending on your
kernel version, and how you've built your kernel Linux may already
do this for you.  If your running a 2.6.29 or newer kernel on a
SMP system the lock owner will be tracked.  This was added to Linux
to support adaptive mutexs, more on that shortly.  Alternately, your
kernel might track the lock owner if you've set CONFIG_DEBUG_MUTEXES
in the kernel build.  If neither of the above things is true for
your kernel the kmutex_t type will include and track the lock owner
to ensure correct behavior.  This is all handled by a new autoconf
check called SPL_AC_MUTEX_OWNER.

Concerning adaptive mutexs these are a very recent development and
they did not make it in to either the latest FC11 of SLES11 kernels.
Ideally, I'd love to see this kernel change appear in one of these
distros because it does help performance.  From Linux kernel commit:
  0d66bf6d3514b35eb6897629059443132992dbd7
  "Testing with Ingo's test-mutex application...
  gave a 345% boost for VFS scalability on my testbox"
However, if you don't want to backport this change yourself you
can still simply export the task_curr() symbol.  The kmutex_t
implementation will use this symbol when it's available to
provide it's own adaptive mutexs.

Finally, DEBUG_MUTEX support was removed including the proc handlers.
This was done because now that we are cleanly integrated with the
kernel profiling all this information and much much more is available
in debug kernel builds.  This code was now redundant.

Update mutexs validated on:
    - SLES10   (ppc64)
    - SLES11   (x86_64)
    - CHAOS4.2 (x86_64)
    - RHEL5.3  (x86_64)
    - RHEL6    (x86_64)
    - FC11     (x86_64)
This commit is contained in:
Brian Behlendorf
2009-09-25 14:47:01 -07:00
parent d28db80fd0
commit 4d54fdee1d
8 changed files with 596 additions and 835 deletions
+20 -23
View File
@@ -23,7 +23,6 @@ AC_DEFUN([SPL_AC_CONFIG_KERNEL], [
SPL_AC_DEBUG
SPL_AC_DEBUG_KMEM
SPL_AC_DEBUG_MUTEX
SPL_AC_DEBUG_KSTAT
SPL_AC_DEBUG_CALLB
SPL_AC_TYPE_UINTPTR_T
@@ -48,6 +47,7 @@ AC_DEFUN([SPL_AC_CONFIG_KERNEL], [
SPL_AC_KMALLOC_NODE
SPL_AC_MONOTONIC_CLOCK
SPL_AC_INODE_I_MUTEX
SPL_AC_MUTEX_OWNER
SPL_AC_MUTEX_LOCK_NESTED
SPL_AC_DIV64_64
SPL_AC_DIV64_U64
@@ -256,28 +256,6 @@ AC_DEFUN([SPL_AC_DEBUG_KMEM], [
fi
])
AC_DEFUN([SPL_AC_DEBUG_MUTEX], [
AC_MSG_CHECKING([whether mutex debugging is enabled])
AC_ARG_ENABLE( [debug-mutex],
AS_HELP_STRING([--enable-debug-mutex],
[Enable mutex debug support (default off)]),
[ case "$enableval" in
yes) spl_ac_debug_mutex=yes ;;
no) spl_ac_debug_mutex=no ;;
*) AC_MSG_RESULT([Error!])
AC_MSG_ERROR([Bad value "$enableval" for --enable-debug-mutex]) ;;
esac ]
)
if test "$spl_ac_debug_mutex" = yes; then
AC_MSG_RESULT([yes])
AC_DEFINE([DEBUG_MUTEX], [1],
[Define to 1 to enable mutex debugging])
KERNELCPPFLAGS="${KERNELCPPFLAGS} -DDEBUG_MUTEX"
else
AC_MSG_RESULT([no])
fi
])
AC_DEFUN([SPL_AC_DEBUG_KSTAT], [
AC_MSG_CHECKING([whether kstat debugging is enabled])
AC_ARG_ENABLE( [debug-kstat],
@@ -825,6 +803,25 @@ AC_DEFUN([SPL_AC_INODE_I_MUTEX], [
])
])
dnl #
dnl # 2.6.29 API change,
dnl # Adaptive mutexs introduced.
dnl #
AC_DEFUN([SPL_AC_MUTEX_OWNER], [
AC_MSG_CHECKING([whether struct mutex has owner])
SPL_LINUX_TRY_COMPILE([
#include <linux/mutex.h>
],[
struct mutex mtx;
mtx.owner = NULL;
],[
AC_MSG_RESULT(yes)
AC_DEFINE(HAVE_MUTEX_OWNER, 1, [struct mutex has owner])
],[
AC_MSG_RESULT(no)
])
])
dnl #
dnl # 2.6.18 API change,
dnl # First introduced 'mutex_lock_nested()' in include/linux/mutex.h,