[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
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:user-agent:date:subject:from:to:cc:message-id :thread-topic:thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=lP51XX9HA9ENCCTf/VwqQ+ZljcAItkcSbAUzRL3+MsE=; b=t/ULtuU5qwKC/VXLhjxtLnutxEjpgSDYavOf/s23eAHZJCa3obiQcAiiZ4HvxYZ2sx jQhTiN4ztjjYSuyRXfHiBKIC1ICuh7wQZiJxIJ9Hkr0G3xq3O1sHqnW+/rQpEtQzgUsy JsC4BkkkEDmPfqQ1xSBZLGk2b4V70T/69Hp6U=
- 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