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

[Keir Fraser <keir.xen@xxxxxxxxx>]

On 02/05/2011 17:36, "Dan Magenheimer" <dan.magenheimer@xxxxxxxxxx> wrote:

> 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.

That is where it gives the best performance boost (because it obviates the
need for read-side locking, with its associated overheads). But there can be
other reasons for using a lock-free synchronisation strategy -- our current
motivation, sync'ing with interrupt handlers (or, similarly, signal handlers
in Unix processes), is another common one.

In terms of the cost of switching to an RCU radix-tree implementation, for
those users that don't need it (i.e., tmem, because you have full lock-based
synchronisation) it looks like node deletions unconditionally wait for an
RCU grace period before freeing the old node. If tmem is doing a reasonable
rate of deletion it might make sense for us to make that optional, selected
when the tree is first initialised. It would be easy enough to add an
'rcu_safe' flag for that purpose. There's also a rcu_head struct added to
every tree node. Not so much we can do about that. It's only 16 bytes,
hopefully not too bad an issue for tmem.

 -- Keir



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