diff options
author | Brian Behlendorf <[email protected]> | 2009-09-25 14:47:01 -0700 |
---|---|---|
committer | Brian Behlendorf <[email protected]> | 2009-09-25 14:47:01 -0700 |
commit | 4d54fdee1d774ddaef381893434a3721067e2c56 (patch) | |
tree | 7139adfd73794aec7103361539b30903a6500572 /include/sys/condvar.h | |
parent | d28db80fd0fd4fd63aec09037c44408e51a222d6 (diff) |
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:
e811949a57044d60d12953c5c3b808a79a7d36ef and
d28db80fd0fd4fd63aec09037c44408e51a222d6
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)
Diffstat (limited to 'include/sys/condvar.h')
-rw-r--r-- | include/sys/condvar.h | 1 |
1 files changed, 1 insertions, 0 deletions
diff --git a/include/sys/condvar.h b/include/sys/condvar.h index 40b6e4948..9a2e8b5a0 100644 --- a/include/sys/condvar.h +++ b/include/sys/condvar.h @@ -33,6 +33,7 @@ extern "C" { #include <linux/module.h> #include <linux/wait.h> +#include <sys/kmem.h> #include <sys/mutex.h> /* The kcondvar_t struct is protected by mutex taken externally before |