WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Re: Performance overhead of paravirt_ops on native identifie

To: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: [Xen-devel] Re: Performance overhead of paravirt_ops on native identified
From: "H. Peter Anvin" <hpa@xxxxxxxxx>
Date: Fri, 22 May 2009 15:47:05 -0700
Cc: Nick Piggin <npiggin@xxxxxxx>, "Xin, Xiaohui" <xiaohui.xin@xxxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Chuck Ebbert <cebbert@xxxxxxxxxx>, Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>, "Li, Xin" <xin.li@xxxxxxxxx>, "Nakajima, Jun" <jun.nakajima@xxxxxxxxx>, Ingo Molnar <mingo@xxxxxxx>
Delivery-date: Fri, 22 May 2009 15:47:55 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4A172ADE.3010702@xxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4A0B62F7.5030802@xxxxxxxx> <20090521184233.3c3e97ad@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <4A15DA4E.2090505@xxxxxxxx> <C85CEDA13AB1CF4D9D597824A86D2B9005760A96DA@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <4A1629BA.9070309@xxxxxxxx> <C85CEDA13AB1CF4D9D597824A86D2B9005760A9940@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <4A16D3DF.5000600@xxxxxxxxx> <4A172ADE.3010702@xxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 2.0.0.21 (X11/20090320)
Jeremy Fitzhardinge wrote:
> 
> I did a quick experiment to see how many sites this optimisation could 
> actually affect.  Firstly, it does absolutely nothing with frame 
> pointers enabled.  Arranging for no frame pointers is quite tricky, 
> since it means disabling all debugging, tracing and other things.
> 
> With no frame pointers, its about 26 of 5400 indirect calls are 
> immediately followed by ret (not all of those sites are pvops calls).  
> With preempt disabled, this goes up to 45 sites.
> 
> I haven't done any actual runtime tests, but a quick survey of the 
> affected sites shows that only a couple are performance-sensitive; 
> _spin_lock and _spin_lock_irq and _spin_lock_irqsave are the most obvious.
> 

OK, that doesn't seem like a very productive avenue.  Problem still
remains, obviously.

        -hpa


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