Date: 16 Mar 2004 16:18:48 +0000 From: Doug Rabson <dfr@nlsystems.com> To: John Baldwin <john@baldwin.cx> Cc: freebsd-arch@FreeBSD.org Subject: Re: Read Copy Update Message-ID: <1079453928.10695.6.camel@builder02.qubesoft.com> In-Reply-To: <200403161012.09174.john@baldwin.cx> References: <1077137806.28133.10.camel@herring.nlsystems.com> <20040316142110.GA6802@technokratis.com> <1079448788.10695.1.camel@builder02.qubesoft.com> <200403161012.09174.john@baldwin.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 2004-03-16 at 15:12, John Baldwin wrote: > 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. I guess I did gloss over a lot of the 'interesting' bits like not losing edge triggered interrupts etc. Still, that part is well understood since its the core of the splX implementation in 4.x and before. I'm not quite sure what you are getting at wrt. ithread preemption? How does that interact with critical_enter/critical_exit?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1079453928.10695.6.camel>