Date: Thu, 19 Feb 2004 09:02:35 +0000 From: Doug Rabson <dfr@nlsystems.com> To: Jeff Roberson <jroberson@mail.chesapeake.net> Cc: freebsd-arch@freebsd.org Subject: Re: Read Copy Update Message-ID: <1077181355.28133.13.camel@herring.nlsystems.com> In-Reply-To: <20040218182136.S5430@mail.chesapeake.net> References: <1077137806.28133.10.camel@herring.nlsystems.com> <20040218182136.S5430@mail.chesapeake.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1077181355.28133.13.camel>