Read Copy Update

[John Baldwin]

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 at baldwin.cx>  <><  http://www.baldwin.cx/~john/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org