Re: [PATCH] Read-Copy Update 2.5.4-pre2

[Dipankar Sarma <dipankar@in.ibm.com>]

On Fri, Feb 08, 2002 at 06:51:52PM -0500, Mark Hahn wrote:
> > in lkml in the past. Currently there are several potential 
> > applications of RCU that are being developed and some of them look 
> > very promising. Our revamped webpage 
> 
> yes, but have you evaluated whether it's noticably better than
> other forms of locking?  for instance, couldn't your dcache example
> simply use BR locks?

First of all, IMO, RCU is not a wholesale replacement for one form of
locking or another. It provides two things -

1. Simplify locking in certain complicated cases - like module
   unloading or Hotplug CPU support.
2. It can used to avoid *both* lock contention and lock cacheline
   bouncing in performance critical code where it makes sense.

Now, I would argue that RCU in this case has less overhead than BR locks.
Sure, BR locks would allow multiple d_lookups to happen, but
all workloads that we looked did not always have heavily
skewed read-to-write ratios. dbench showed about 4:1 ratio,
httperf showed about 3:1 ratio, other workloads even less skewed.
That is not good for BR locks. Remember, apart from the contention
with the update side, there is also the overhead of that CPU's
BR lock cacheline miss in lookup.

Thanks
Dipankar
-- 
Dipankar Sarma  <dipankar@in.ibm.com> http://lse.sourceforge.net
Linux Technology Center, IBM Software Lab, Bangalore, India.