[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Read Copy Update
- Subject: Read Copy Update
- From: john at baldwin.cx (John Baldwin)
- Date: Tue Mar 16 08:07:59 2004
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_(_dot_)_cx> <>< http://www.baldwin.cx/~john/
"Power Users Use the Power to Serve" = http://www.FreeBSD.org