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

[Keir Fraser <keir.xen@gmail.com>]

On 02/05/2011 13:00, "Jan Beulich" <JBeulich@novell.com> wrote:

>> (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.
> 
> 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).

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.

 -- Keir