From owner-freebsd-arch@FreeBSD.ORG Thu Feb 19 01:02:48 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1E4BF16A4CE for ; Thu, 19 Feb 2004 01:02:48 -0800 (PST) Received: from herring.nlsystems.com (mailgate.nlsystems.com [80.177.232.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id A33FB43D1D for ; Thu, 19 Feb 2004 01:02:47 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from [10.0.0.2] (herring.nlsystems.com [10.0.0.2]) i1J92ZF1038512; Thu, 19 Feb 2004 09:02:36 GMT (envelope-from dfr@nlsystems.com) From: Doug Rabson To: Jeff Roberson In-Reply-To: <20040218182136.S5430@mail.chesapeake.net> References: <1077137806.28133.10.camel@herring.nlsystems.com> <20040218182136.S5430@mail.chesapeake.net> Content-Type: text/plain Message-Id: <1077181355.28133.13.camel@herring.nlsystems.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Thu, 19 Feb 2004 09:02:35 +0000 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on herring.nlsystems.com cc: freebsd-arch@freebsd.org Subject: Re: Read Copy Update X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2004 09:02:48 -0000 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.