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>
index | next in thread | previous in thread | raw e-mail
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.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1077181355.28133.13.camel>