Read Copy Update

Doug Rabson dfr at nlsystems.com
Thu Feb 19 01:02:48 PST 2004


On Wed, 2004-02-18 at 23:26, Jeff Roberson wrote:
> On Wed, 18 Feb 2004, Doug Rabson wrote:
> 
> > So, I was reading the latest installment of the SCO soap on slashdot
> > today (bizarre - they seem to be claiming that they own all code that
> > was ever linked to a System V kernel) and I ended up trying to figure
> > out exactly what this RCU thing is that they claim is infringing their
> > right to obtain money with menaces.
> >
> > I read one of the original papers at
> > http://www.rdrop.com/users/paulmck/paper/rclockpdcsproof.pdf and its a
> > surprisingly simple idea. Basically for certain data structures which
> > are read-mostly, you can make the entire read path lock-free at the
> > expense of making updates quite a bit more expensive. They claim that
> > its much faster than reader-writer locks both for light contention and
> > for heavy contention.
> >
> > I imagine that a FreeBSD implementation of RCU wouldn't actually be too
> > hard and it might be well worth it as an alternative way of managing
> > concurrency, e.g. for the routing cache and the name cache (and probably
> > lots of other things).
> >
> 
> I've looked into this a bit myself.  My general feeling is that it would
> not be terribly difficult to do, but I would prefer to start with stronger
> primitives and work our way into more efficient mechanisms.  I say this
> for two reasons.  First, as a general rule of optimizations, you only
> optimize the things that need it.  I think we should wait and measure
> contention and then optimize things.  Secondly, we need to get more
> confidence in the correctness of simpler mechanisms in most subsystems
> before we go to something more complex.  It will be easier to move to RCU
> once a subsystem is already protected by mutexes.
> 
> I think that this is a good path to go down, but I really don't think
> we're ready yet.  I'd rather see energy spent protecting code than
> building more infrastructure.

I completely agree. I was just musing about this as a future addition to
the locking toolbox. Its certainly not worth trying before enough of the
kernel is outside the giant lock to make it worthwhile.




More information about the freebsd-arch mailing list