From owner-freebsd-arch@FreeBSD.ORG Mon Mar 15 19:18:46 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 8CFAF16A4CE for ; Mon, 15 Mar 2004 19:18:46 -0800 (PST) Received: from smtp.distributel.net (cns2.distributel.NET [66.38.181.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 18A1943D46 for ; Mon, 15 Mar 2004 19:18:46 -0800 (PST) (envelope-from bmilekic@technokratis.com) Received: from godel.mtl.distributel.net (nat.MTL.distributel.NET [66.38.181.24]) by smtp.distributel.net (8.12.6/8.12.6) with ESMTP id i2G3IiM2033027; Mon, 15 Mar 2004 22:18:44 -0500 (EST) Received: from godel.mtl.distributel.net (localhost [127.0.0.1]) i2G3H36p003829; Mon, 15 Mar 2004 22:17:03 -0500 (EST) (envelope-from bmilekic@technokratis.com) Received: (from bmilekic@localhost)i2G3H3vm003828; Mon, 15 Mar 2004 22:17:03 -0500 (EST) (envelope-from bmilekic@technokratis.com) X-Authentication-Warning: godel.mtl.distributel.net: bmilekic set sender to bmilekic@technokratis.com using -f Date: Mon, 15 Mar 2004 22:17:03 -0500 From: Bosko Milekic To: Doug Rabson Message-ID: <20040316031702.GA3794@technokratis.com> References: <1077137806.28133.10.camel@herring.nlsystems.com> <20040218182136.S5430@mail.chesapeake.net> <1077181355.28133.13.camel@herring.nlsystems.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1077181355.28133.13.camel@herring.nlsystems.com> User-Agent: Mutt/1.4.1i 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: Tue, 16 Mar 2004 03:18:46 -0000 On Thu, Feb 19, 2004 at 09:02:35AM +0000, Doug Rabson wrote: > 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. As Jeff said and you agree, it is probably too early for this now. Also, I've looked at the paper you quote before SCO's announcement (which by the way I had no idea about until now), and I think we'll eventually do just as well in the common case without going to the RCU model at all. -- Bosko Milekic * bmilekic@technokratis.com * bmilekic@FreeBSD.org TECHNOkRATIS Consulting Services * http://www.technokratis.com/ "It is impossible for anyone to begin to learn what he believes he already knows." -- Epictetus (c.a.d. 55-c135)