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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/