From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: [PATCH 1/2, v2] x86: replace nr_irqs sized per-domain arrays with radix trees Date: Wed, 04 May 2011 08:27:56 +0100 Message-ID: <4DC11C1C020000780003F9DF@vpn.id2.novell.com> References: <4DC02878020000780003F690@vpn.id2.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: "xen-devel@lists.xensource.com" , Allen M Kay List-Id: xen-devel@lists.xenproject.org >>> On 03.05.11 at 23:08, Keir Fraser wrote: > On 03/05/2011 15:08, "Jan Beulich" wrote: >=20 >> 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... >>=20 >> 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). >=20 > 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. Jan