Date: 16 Mar 2004 14:53:08 +0000 From: Doug Rabson <dfr@nlsystems.com> To: Bosko Milekic <bmilekic@technokratis.com> Cc: freebsd-arch@FreeBSD.org Subject: Re: Read Copy Update Message-ID: <1079448788.10695.1.camel@builder02.qubesoft.com> In-Reply-To: <20040316142110.GA6802@technokratis.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> <20040316142110.GA6802@technokratis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 2004-03-16 at 14:21, Bosko Milekic wrote: > 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. I was imagining a a pcpu flag which was a 'soft cli', i.e. if a cpu fields an interrupt and the soft cli flag is set, it just clears the interrupt flag in the trapframe and returns. It all works out the same in the end. > > > 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. Agreed.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1079448788.10695.1.camel>