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

[Keir Fraser <keir.xen@xxxxxxxxx>]

On 03/05/2011 10:35, "Jan Beulich" <JBeulich@xxxxxxxxxx> wrote:

>> Oh, another way would be to make lookup_slot invocations from IRQ context be
>> RCU-safe. Then the radix tree updates would not have to synchronise on the
>> irq_desc lock? And I believe Linux has examples of RCU-safe usage of radix
>> trees -- certainly Linux's radix-tree.h mentions RCU.
>> 
>> I must say this would be far more attractive to me than hacking the xmalloc
>> subsystem. That's pretty nasty.
> 
> I think that I can actually get away with two stage insertion/removal
> without needing RCU, based on the fact that prior to these changes
> we have the translation arrays also hold zero values that mean "does
> not have a valid translation". Hence I can do tree insertion (removal)
> with just d->event_lock held, but data not yet (no longer) populated,
> and valid <-> invalid transitions only happening with the IRQ's
> descriptor lock held (and interrupts disabled). All this requires is that
> readers properly deal with the non-populated state, which they
> already had to in the first version of the patch anyway.

But the readers in irq context will call lookup_slot() without d->event_lock
held? In that case you do need an RCU-aware version of radix-tree.[ch],
because lookups can be occurring concurrently with insertions/deletions.
Good news is that the RCU-aware radix tree implementation hides the RCU
details from you entirely.

Well, in any case, I'm happy to iterate on this patch if necessary.

 -- Keir



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