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

["Jan Beulich" <JBeulich@xxxxxxxxxx>]

>>> On 03.05.11 at 12:09, Keir Fraser <keir.xen@xxxxxxxxx> wrote:
> 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.

No, in IRQ context we only need the irq -> pirq translation afaics, and
that translation doesn't use an allocated object (it instead simply inserts
the [non-zero] pirq as data item).

Jan


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