Re: Fileassoc locking

[David Laight <david%l8s.co.uk@localhost>]

On Sat, Dec 26, 2009 at 01:50:55AM +0100, Adam Hamsik wrote:
> 
> RW locks have some performance problems, and they should not be used
> until it's needed.
> I think that same think can be accomplished by using reference
> counters and mutexes/cv variables.

A RW lock has to do a mutex acquire/release when it is acquired and
released - so has twice as many locked bus cycles as a simple mutex.
As such it isn't that different from a locked reference count (after
all that is what has to happen to allow multiple readers of a RW lock).

Unless you actually want a RW lock, it probably isn't what you should
be using. Separate mutex and CV give you a lot more flexibility [1].

> Rw locks has very bad effect on CPU caches and can slow things
> down on a bigger SMP systems.

Actually RW locks are probably only ever worthwhile on big SMP systems!
RW locks allow additional concurrency! The chance of mutex contention
is roughly the % of time spent with the mutex held multiplied by the
number of cpus (assuming you don't actually sleep with the mutex held).
So unless the mutex is held for a long time and there are a lot of cpus
then contention is relatively unlikely (particularly with a real workload).

It is much like other places where having too fine grained locks slows
things down (as well as making the locking hierarchy too complex).

        David

[1] Hampered when some C++ lock library derives 'condvar' from 'mutex'
thus stopping you using the same mutex for many CV.

-- 
David Laight: david%l8s.co.uk@localhost