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: [PATCH RFC V2 3/5] jump_label: if a key has already been

To: Steven Rostedt <rostedt@xxxxxxxxxxx>
Subject: [Xen-devel] Re: [PATCH RFC V2 3/5] jump_label: if a key has already been initialized, don't nop it out
From: Richard Henderson <rth@xxxxxxxxxx>
Date: Thu, 06 Oct 2011 11:50:24 -0700
Cc: Jeremy Fitzhardinge <jeremy@xxxxxxxx>, the arch/x86 maintainers <x86@xxxxxxxxxx>, Jeremy Fitzhardinge <jeremy.fitzhardinge@xxxxxxxxxx>, David Daney <david.daney@xxxxxxxxxx>, peterz@xxxxxxxxxxxxx, Jason Baron <jbaron@xxxxxxxxxx>, Jan Glauber <jang@xxxxxxxxxxxxxxxxxx>, Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>, Michael Ellerman <michael@xxxxxxxxxxxxxx>, Xen Devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, "H. Peter Anvin" <hpa@xxxxxxxxx>, "David S. Miller" <davem@xxxxxxxxxxxxx>
Delivery-date: Sun, 09 Oct 2011 09:26:19 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1317925615.4729.14.camel@xxxxxxxxxxxxxxxxxxx>
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: <cover.1317506051.git.jeremy.fitzhardinge@xxxxxxxxxx> <477dead9647029012f93c651f2892ed0e86b89e7.1317506051.git.jeremy.fitzhardinge@xxxxxxxxxx> <20111003150205.GB2462@xxxxxxxxxx> <4E89E28C.7010700@xxxxxxxx> <20111004141011.GA2520@xxxxxxxxxx> <4E8B3489.60902@xxxxxxxxx> <4E8CF348.4080405@xxxxxxxx> <4E8CF385.2080804@xxxxxxxxx> <4E8DEB19.1050509@xxxxxxxx> <20111006181055.GA2505@xxxxxxxxxx> <1317925615.4729.14.camel@xxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2
On 10/06/2011 11:26 AM, Steven Rostedt wrote:
> On Thu, 2011-10-06 at 14:10 -0400, Jason Baron wrote:
> 
>>> Looks like jmp2 is about 5% faster than jmp5 on Sandybridge with this
>>> benchmark.
>>>
>>> But insignificant difference on Nehalem.
>>>
>>>     J
>>
>> It would be cool if we could make the total width 2-bytes, when
>> possible.  It might be possible by making the initial 
>> 'JUMP_LABEL_INITIAL_NOP'
>> as a 'jmp' to the 'l_yes' label. And then patching that with a no-op at boot
>> time or link time - letting the compiler pick the width. In that way we could
>> get the optimal width...
> 
> Why not just do it?
> 
> jump_label is encapsulated in arch_static_branch() which on x86 looks
> like:
> 
> static __always_inline bool arch_static_branch(struct jump_label_key *key)
> {
>       asm goto("1:"
>               JUMP_LABEL_INITIAL_NOP
>               ".pushsection __jump_table,  \"aw\" \n\t"
>               _ASM_ALIGN "\n\t"
>               _ASM_PTR "1b, %l[l_yes], %c0 \n\t"
>               ".popsection \n\t"
>               : :  "i" (key) : : l_yes);
>       return false;
> l_yes:
>       return true;
> }
> 
> 
> That jmp to l_yes should easily be a two byte jump.

Until the compiler decides to re-order the code.  That's the problem --
in the general case you do not know how far away the destination is really
going to be.

There are a couple of possibilities for improvement:

(1) Do as Jason suggests above and let the assembler figure out the size
of the branch that is needed.  Without adding more data to __jump_table,
you'll want to be extremely careful about checking the two pointers to 
see what size branch has been installed.

(2) Always reserve 5 bytes of space, but if the distance is small enough
patch in a 2-byte jump.  That doesn't help with the icache footprint.

(3) There is no 3.  I was going to say something clever about gas .ifne
conditionals, but a quick test revealed they don't work for forward
declarations.



r~


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

<Prev in Thread] Current Thread [Next in Thread>