Re: [PATCH] First casuality of hlist poisoning in 2.5.70

[Paul E. McKenney]

On Thu, Jun 12, 2003 at 05:26:27PM +0100, [e-mail] wrote:
> We _do_ need to sort out the situation with unhashing stuff in NFS - in
> particular, the way it deals with mountpoints and with directories is
> a mess.  I'm looking through that code, but it's bloody slow analysis
> due to RCU.  Premature optimizations and all such...

No arguments on NFS, and I have to agree that RCU has been used
primarily as an optimization thus far in Linux.  However, RCU
can and should be considered quite early on.  The situation is
similar to reader-writer locking -- you are better off working
out which of your locks are going to be reader-writer locks
earlier rather than later.  If you use either reader-writer
locking or RCU as a late optimization, you will find that your
earlier design decisions make your life more complex than necessary.

On the other hand, if RCU is considered early, it can make life
simpler.  Breaking up locks often introduces deadlocks.  Some
of these deadlocks can be avoided entirely by thinking through
the use of RCU at design time.  An extreme example of deadlock
avoidance may be found in IPMI (drivers/char/ipmi/ipmi_kcs_intf.c,
the synchronize_kernel() near line 1174).  Really tough to do
this as a late optimization...

						Thanx, Paul