| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
[Xen-devel] Re: Performance overhead of paravirt_ops on native identifie
|
To: |
"Xin, Xiaohui" <xiaohui.xin@xxxxxxxxx> |
|
Subject: |
[Xen-devel] Re: Performance overhead of paravirt_ops on native identified |
|
From: |
"H. Peter Anvin" <hpa@xxxxxxxxx> |
|
Date: |
Thu, 21 May 2009 20:39:01 -0700 |
|
Cc: |
Nick Piggin <npiggin@xxxxxxx>, Jeremy Fitzhardinge <jeremy@xxxxxxxx>, 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: |
Thu, 21 May 2009 20:39:43 -0700 |
|
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxxx |
|
In-reply-to: |
<C85CEDA13AB1CF4D9D597824A86D2B9005760A96DA@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> |
|
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> |
|
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
|
User-agent: |
Thunderbird 2.0.0.14 (X11/20080501) |
Xin, Xiaohui wrote:
> Remember we have done one experiment with "jump", the result shows seems the
> overhead is even more than the call.
I didn't, no. That seems extremely weird to me.
(Unbalancing the call/ret stack is known to suck royally, of course.)
>>>
>>>
>> Can't those calls be changed to jumps?
>>
>
> In this specific instance of this example, yes. But if you start
> enabling various spinlock debug options then there'll be code following
> the call. It would be hard for the runtime patching machinery to know
> when it would be safe to do the substitution.
>
When there is code after the call, it's rather obviously not safe.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
| <Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: [Xen-devel] Performance overhead of paravirt_ops on nativeidentified, (continued)
Re: [Xen-devel] Performance overhead of paravirt_ops on nativeidentified, Peter Zijlstra
[Xen-devel] [tip:x86/urgent] x86: Fix performance regression caused by paravirt_ops on native kernels, tip-bot for Jeremy Fitzhardinge
[Xen-devel] Re: Performance overhead of paravirt_ops on native identified, Chuck Ebbert
- [Xen-devel] Re: Performance overhead of paravirt_ops on native identified, Jeremy Fitzhardinge
- [Xen-devel] Re: Performance overhead of paravirt_ops on native identified, H. Peter Anvin
- [Xen-devel] RE: Performance overhead of paravirt_ops on native identified, Xin, Xiaohui
- [Xen-devel] Re: Performance overhead of paravirt_ops on native identified,
H. Peter Anvin <=
- [Xen-devel] Re: Performance overhead of paravirt_ops on native identified, Jeremy Fitzhardinge
- [Xen-devel] RE: Performance overhead of paravirt_ops on native identified, Xin, Xiaohui
- [Xen-devel] Re: Performance overhead of paravirt_ops on native identified, H. Peter Anvin
- [Xen-devel] Re: Performance overhead of paravirt_ops on native identified, Jeremy Fitzhardinge
- [Xen-devel] Re: Performance overhead of paravirt_ops on native identified, H. Peter Anvin
|
|
|
| |
|
Home