WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Jan Beulich <JBeulich@xxxxxxxxxx>
Subject: Re: [Xen-devel] [xen-unstable test] 6947: regressions - trouble: broken/fail/pass
From: Keir Fraser <keir.xen@xxxxxxxxx>
Date: Tue, 03 May 2011 11:09:33 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 03 May 2011 03:10:47 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:user-agent:date:subject:from:to:cc:message-id :thread-topic:thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=YrToF2VKixhytU9Xy8+TYfarh64PDfeyBsEr/nGUFFQ=; b=hoFywbGm/XwmleLCGDBUCXWjaH1Yl4Yr99pga6b6kVZmTnkVQy0gIsoGiEc6PSNFxF Un+ONjPO7iIxlJ1s970ilXqeAJqHXB5b5TQOlB5WH/3tECl0bwlis+PfwlLQc0SKtSSZ MJsFbHUjdS3R9xxnw6Dfo2dGcmcFAbG9lNAbE=
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=vQ31FDsUDX5Zn/ughFHzSMfBq2h7XkL/aDBq7+B7CBVj/VyKKbAeVhuU/X4Pl/xaLG 6enoPVB3NZgrw8Iut3kEeqmH7D01ygrUUxzuloW2fOh8u7MG35sAjHDFl/dlz8xx3Qgb KIdRuZEOyIcMxAi7VbNa5ezPcAlmaLmGn9nI0=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4DBFE886020000780003F5AD@xxxxxxxxxxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcwJejLPkO5EgfAJf0GJSnoL14MLXw==
Thread-topic: [Xen-devel] [xen-unstable test] 6947: regressions - trouble: broken/fail/pass
User-agent: Microsoft-Entourage/12.29.0.110113
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