Date: Tue, 16 Mar 2004 09:21:10 -0500 From: Bosko Milekic <bmilekic@technokratis.com> To: Doug Rabson <dfr@nlsystems.com> Cc: freebsd-arch@FreeBSD.org Subject: Re: Read Copy Update Message-ID: <20040316142110.GA6802@technokratis.com> In-Reply-To: <200403160914.51727.dfr@nlsystems.com> References: <1077137806.28133.10.camel@herring.nlsystems.com> <1077181355.28133.13.camel@herring.nlsystems.com> <20040316031702.GA3794@technokratis.com> <200403160914.51727.dfr@nlsystems.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Mar 16, 2004 at 09:14:51AM +0000, Doug Rabson wrote: > 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. Should be really easy to fix in the common case without having to get really fancy (e.g., just interlock against ourselves on a private per-thread flag) to merely delay cli until the first interrupt. We shouldn't need to mask out per CPU or anything fancy like that. > 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. Yeah, that sucks. -- 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)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040316142110.GA6802>