]> git.proxmox.com Git - mirror_spl-debian.git/commit
Update rwlocks to track owner to ensure correct semantics
authorBrian Behlendorf <behlendorf1@llnl.gov>
Fri, 25 Sep 2009 21:14:35 +0000 (14:14 -0700)
committerBrian Behlendorf <behlendorf1@llnl.gov>
Fri, 25 Sep 2009 21:14:35 +0000 (14:14 -0700)
commitd28db80fd0fd4fd63aec09037c44408e51a222d6
tree5a0d35c042fe4ae8146b59715dcbb73dbd27a37b
parente811949a57044d60d12953c5c3b808a79a7d36ef
Update rwlocks to track owner to ensure correct semantics

The behavior of RW_*_HELD was updated because it was not quite right.
It is not sufficient to return non-zero when the lock is help, we must
only do this when the current task in the holder.

This means we need to track the lock owner which is not something
tracked in a Linux semaphore.  After some experimentation the
solution I settled on was to embed the Linux semaphore at the start
of a larger krwlock_t structure which includes the owner field.
This maintains good performance and allows us to cleanly intergrate
with the kernel lock analysis tools.  My reasons:

1) By placing the Linux semaphore at the start of krwlock_t we can
then simply cast krwlock_t to a rw_semaphore and pass that on to
the linux kernel.  This allows us to use '#defines so the preprocessor
can do direct replacement of the Solaris primative with the linux
equivilant.  This is important because it then maintains the location
information for each rw_* call point.

2) Additionally, by adding the owner to krwlock_t we can keep this
needed extra information adjacent to the lock itself.  This removes
the need for a fancy lookup to get the owner which is optimal for
performance.  We can also leverage the existing spin lock in the
semaphore to ensure owner is updated correctly.

3) All helper functions which do not need to strictly be implemented
as a define to preserve location information can be done as a static
inline function.

4) Adding the owner to krwlock_t allows us to remove all memory
allocations done during lock initialization.  This is good for all
the obvious reasons, we do give up the ability to specific the lock
name.  The Linux profiling tools will stringify the lock name used
in the code via the preprocessor and use that.

Update rwlocks validated on:
- SLES10   (ppc64)
- SLES11   (x86_64)
- CHAOS4.2 (x86_64)
- RHEL5.3  (x86_64)
- RHEL6    (x86_64)
- FC11     (x86_64)
include/sys/rwlock.h
module/spl/spl-generic.c
module/spl/spl-rwlock.c