[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: Jan Beulich <JBeulich@xxxxxxxxxx>
  • From: Keir Fraser <keir.xen@xxxxxxxxx>
  • Date: Mon, 02 May 2011 13:19:45 +0100
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Mon, 02 May 2011 05:20:43 -0700
  • 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=n17MTM0OnXEGNdHhYtRYUVgs9ZFXCGhrHykUDzgyMqC02aYRHwtHYOAOARZXDERSl+ RbatZinCJRR7yHVIosb7ep3xD9+gZSuZkJh4/RP69wLRM4mm2eqrjYg1EnuQGuv0XMuo 24q0f6lDWp86zSdrkYm2Suang0GjjgYdDuPEI=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcwIwzi2pwZqzLk7SkGfAj3+4Ixx3Q==
  • Thread-topic: [Xen-devel] [xen-unstable test] 6947: regressions - trouble: broken/fail/pass

On 02/05/2011 13:00, "Jan Beulich" <JBeulich@xxxxxxxxxx> 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



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.