RE: [Xen-devel] [xen-unstable test] 6947: regressions - trouble: broken/fail/pass

[Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>]

> No, I think you just misunderstand RCU. What I (and now also you, a bit
> independently ;-) have described is how to synchronise writers against
> other
> writers -- e.g., someone inserting concurrently with deleting, as you
> describe above. What RCU is all about is synchronising *readers*
> against
> writers, without needing a lock. And we still need it because the
> radix-tree
> updates will happen under d->event_lock, which the readers in IRQ
> context
> will not be holding. The main thing that RCU generally needs is that,
> when a
> node is deleted from a structure (radix-tree in this case) it cannot be
> freed until an RCU grace period because concurrent lock-free readers
> may
> still hold a pointer to it. There are also other details to consider
> but
> actually the whole RCU issue appears to be handled by Linux's radix-
> tree
> implementation -- we just need to pull an up-to-date version across
> into
> Xen.

I won't claim to understand RCU very well either, but I
actually explicitly chose a pre-RCU version of the Linux
radix tree code because tmem (which was the only user of
the radix tree code at the time IIRC) is write-often
AND read-often and my understanding of RCU is that it
works best for read-often-write-infrequently trees.

Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel