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


Re: [Xen-devel] [PATCH 1/2, v2] x86: replace nr_irqs sized per-domain ar

To: "Keir Fraser" <keir@xxxxxxx>
Subject: Re: [Xen-devel] [PATCH 1/2, v2] x86: replace nr_irqs sized per-domain arrays with radix trees
From: "Jan Beulich" <JBeulich@xxxxxxxxxx>
Date: Wed, 04 May 2011 08:27:56 +0100
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Allen M Kay <allen.m.kay@xxxxxxxxx>
Delivery-date: Wed, 04 May 2011 00:28:53 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C9E62D62.2CE08%keir@xxxxxxx>
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>
References: <4DC02878020000780003F690@xxxxxxxxxxxxxxxxxx> <C9E62D62.2CE08%keir@xxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> On 03.05.11 at 23:08, Keir Fraser <keir@xxxxxxx> wrote:
> On 03/05/2011 15:08, "Jan Beulich" <JBeulich@xxxxxxxxxx> wrote:
>> It would seem possible to fold the two trees into one (making e.g. the
>> emuirq bits stored in the upper half of the pointer), but I'm not
>> certain that's worth it as it would make deletion of entries more
>> cumbersome. Unless pirq-s and emuirq-s were mutually exclusive...
>> v2: Split setup/teardown into two stages - (de-)allocation (tree node
>> (de-)population) is done with just d->event_lock held (and hence
>> interrupts enabled), while actual insertion/removal of translation data
>> gets done with irq_desc's lock held (and interrupts disabled).
> This is mostly okay, because the only operations that occur with irqs
> disabled are read-only on the radix-rtree structure itself, hence no
> alloc/dealloc will happen. *However* those calls to
> radix_tree_lookup[_slot]() are not synchronised wrt your calls to
> radix_tree_{insert,delete}(). The latter hold d->event_lock, while the
> former do not. Hence you need RCU and you need a new first patch in your
> patch set to pull in a modern radix-tree.[ch] from upstream Linux.

Right you are - I didn't pay attention to the tree internal nodes.
Will take a few days though before I can get to this.


Xen-devel mailing list