Date: Tue, 16 Mar 2004 10:12:09 -0500 From: John Baldwin <john@baldwin.cx> To: arch@FreeBSD.org Cc: freebsd-arch@FreeBSD.org Subject: Re: Read Copy Update Message-ID: <200403161012.09174.john@baldwin.cx> In-Reply-To: <1079448788.10695.1.camel@builder02.qubesoft.com> References: <1077137806.28133.10.camel@herring.nlsystems.com> <20040316142110.GA6802@technokratis.com> <1079448788.10695.1.camel@builder02.qubesoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday 16 March 2004 09:53 am, Doug Rabson wrote: > 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. I have this partly implemented, but because the VM86 code really sucks (it just always enables interrupts) the invariants checks I have don't make it to single user mode. I haven't decided what to do about VM86 yet, and I also haven't handled the problem of switching away from interrupt context (for ithread preemption) and switching back and making that all work correctly w/o possibly dropping interrupts. -- John Baldwin <john@baldwin.cx> <>< http://www.baldwin.cx/~john/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200403161012.09174.john>