From owner-freebsd-arch@FreeBSD.ORG Tue Mar 16 01:15:04 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 9B91516A4CE for ; Tue, 16 Mar 2004 01:15:04 -0800 (PST) Received: from herring.rabson.org (mailgate.nlsystems.com [80.177.232.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id CB48A43D46 for ; Tue, 16 Mar 2004 01:15:03 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from herring.rabson.org (herring.rabson.org [10.0.0.2]) by herring.rabson.org (8.12.11/8.12.11) with ESMTP id i2G9EqUY012694; Tue, 16 Mar 2004 09:14:52 GMT (envelope-from dfr@nlsystems.com) From: Doug Rabson To: Bosko Milekic Date: Tue, 16 Mar 2004 09:14:51 +0000 User-Agent: KMail/1.6.1 References: <1077137806.28133.10.camel@herring.nlsystems.com> <1077181355.28133.13.camel@herring.nlsystems.com> <20040316031702.GA3794@technokratis.com> In-Reply-To: <20040316031702.GA3794@technokratis.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200403160914.51727.dfr@nlsystems.com> X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on herring.rabson.org X-Virus-Scanned: ClamAV version 'clamd / ClamAV version 0.65', clamav-milter version '0.60p' 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 09:15:04 -0000 On Tuesday 16 March 2004 03:17, Bosko Milekic wrote: > On Thu, Feb 19, 2004 at 09:02:35AM +0000, Doug Rabson wrote: > > On Wed, 2004-02-18 at 23:26, Jeff Roberson wrote: > > > > > > 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. Its a pretty neat idea though. I like the sound of being able to e.g. read from the namecache without needing to take an expensive lock. With the way 5-CURRENT works, we would probably still need to suppress context switching which is expensive on intel processors in the current implementation. I guess that could be fixed using some kind of lazy-cli scheme. The main barrier here (apart from the need to push Giant down in more places and stabilise the existing implementation) is IBM's patent. The SCO IP claim (bogus as it is) only covers Sequent's original implementation.