This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: Keir Fraser <keir.xen@xxxxxxxxx>, Jan Beulich <JBeulich@xxxxxxxxxx>
Subject: RE: [Xen-devel] [xen-unstable test] 6947: regressions - trouble: broken/fail/pass
From: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>
Date: Mon, 2 May 2011 09:36:10 -0700 (PDT)
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 02 May 2011 09:37:45 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C9E4900E.17180%keir.xen@xxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4DBED61F020000780003F2D3@xxxxxxxxxxxxxxxxxx C9E4900E.17180%keir.xen@xxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> 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.


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>