From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: [xen-unstable test] 6947: regressions - trouble: broken/fail/pass Date: Mon, 02 May 2011 13:29:59 +0100 Message-ID: <4DBEBFE7020000780003F29F@vpn.id2.novell.com> References: <4DBEB8FA020000780003F276@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 List-Id: xen-devel@lists.xenproject.org >>> On 02.05.11 at 14:19, Keir Fraser wrote: > On 02/05/2011 13:00, "Jan Beulich" wrote: >=20 >>> (3) Restructure the interrupt code to do less work in IRQ context. For >>> example tasklet-per-irq, and schedule on the local cpu. Protect a = bunch of >>> the PIRQ structures with a non-IRQ lock. Would increase interrupt = latency if >>> the local CPU is interrupted in hypervisor context. I'm not sure about = this >>> one -- I'm not that happy about the amount of work now done in hardirq >>> context, but I'm not sure on the performance impact of deferring the = work. >>=20 >> I'm not inclined to make changes in this area for the purpose at hand >> either (again, Linux gets away without this - would have to check how >> e.g. KVM gets the TLB flushing done, or whether they don't defer >> flushes like we do). >=20 > 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 I'm not sure - the patch doesn't introduce the locking (i.e. the translation arrays used without the patch also get updated under lock). I'm also not certain about slot recycling aspects (i.e. what would the result be if freeing slots got deferred via RCU, but the same slot is then needed to be used again before the grace period expires). Quite possibly this consideration is mute, just resulting from my only half-baked understanding of RCU... Jan > trees -- certainly Linux's radix-tree.h mentions RCU. >=20 > I must say this would be far more attractive to me than hacking the = xmalloc > subsystem. That's pretty nasty. >=20 > -- Keir