Xen project Mailing List

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

From: Keir Fraser <keir.xen@xxxxxxxxx>

Date: Tue, 03 May 2011 15:09:10 +0100

Delivery-date: Tue, 03 May 2011 07:13:43 -0700

Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; b=Imjhrjf8DAJiv23G9t4Mo2HTue0kY0K0E/0D02l441N3qHaI+bn55LXVxrSxtiFlof y+Oavrdypnc5Y/IfhVt25QOXDOffjtwDVBcSYRN9GRqjfJch/ouNOozjyFzLe7SUAPBr Yp1oxDW6v2bfLCgRMXVft9iM8Ll+1OV3MRpQw=

List-id: Xen developer discussion <xen-devel.lists.xensource.com>

Thread-index: AcwJm6wry2BEwS9B6kGwZ/A2YJLqfw==

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

On 03/05/2011 14:36, "Jan Beulich" <JBeulich@xxxxxxxxxx> wrote: >> 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). Ah well that makes things easier. :-) If a single lock protects all operations (including lookups) on a particular radix tree then of course we don't need RCU. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel

©2013 Xen Project, A Linux Foundation Collaborative Project. All Rights Reserved.
Linux Foundation is a registered trademark of The Linux Foundation.
Xen Project is a trademark of The Linux Foundation.