All of lore.kernel.org
 help / color / mirror / Atom feed
From: jiang.liu@huawei.com (Jiang Liu (Gerry))
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 6/7] arm64, jump label: optimize jump label implementation
Date: Fri, 18 Oct 2013 11:31:22 +0800	[thread overview]
Message-ID: <5260AB8A.2060505@huawei.com> (raw)
In-Reply-To: <20131017112713.2638910f@gandalf.local.home>


On 2013/10/17 23:27, Steven Rostedt wrote:
> On Thu, 17 Oct 2013 22:40:32 +0800
> Jiang Liu <liuj97@gmail.com> wrote:
>
>
>>>>> You could make the code more concise by limiting your patching ability to
>>>>> branch immediates. Then a nop is simply a branch to the next instruction (I
>>>>> doubt any modern CPUs will choke on this, whereas the architecture requires
>>>>> a NOP to take time).
>>>> I guess a NOP should be more effecient than a "B #4" on real CPUs:)
>>>
>>> Well, I was actually questioning that. A NOP *has* to take time (the
>>> architecture prevents implementations from discaring it) whereas a static,
>>> unconditional branch will likely be discarded early on by CPUs with even
>>> simple branch prediction logic.
>> I naively thought "NOP" is cheaper than a "B" :(
>> Will use a "B #1" to replace "NOP".
>>
>
> Really?? What's the purpose of a NOP then? It seems to me that an
> architecture is broken if a NOP is slower than a static branch.
>
> -- Steve
Hi Steve and Will,
	I have discussed this with one of our chip design members.
He thinks "NOP" should be better than "B #1" because jump instruction
is one of the most complex instructions for microarchitecture, which
may stall the pipeline. And NOP should be friendly enough for all
microarchitectures. So I will keep the "NOP" version.
Thanks!
Gerry

WARNING: multiple messages have this Message-ID (diff)
From: "Jiang Liu (Gerry)" <jiang.liu@huawei.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Jiang Liu <liuj97@gmail.com>, Will Deacon <will.deacon@arm.com>,
	"Catalin Marinas" <Catalin.Marinas@arm.com>,
	Sandeepa Prabhu <sandeepa.prabhu@linaro.org>,
	Marc Zyngier <Marc.Zyngier@arm.com>,
	"Arnd Bergmann" <arnd@arndb.de>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3 6/7] arm64, jump label: optimize jump label implementation
Date: Fri, 18 Oct 2013 11:31:22 +0800	[thread overview]
Message-ID: <5260AB8A.2060505@huawei.com> (raw)
In-Reply-To: <20131017112713.2638910f@gandalf.local.home>


On 2013/10/17 23:27, Steven Rostedt wrote:
> On Thu, 17 Oct 2013 22:40:32 +0800
> Jiang Liu <liuj97@gmail.com> wrote:
>
>
>>>>> You could make the code more concise by limiting your patching ability to
>>>>> branch immediates. Then a nop is simply a branch to the next instruction (I
>>>>> doubt any modern CPUs will choke on this, whereas the architecture requires
>>>>> a NOP to take time).
>>>> I guess a NOP should be more effecient than a "B #4" on real CPUs:)
>>>
>>> Well, I was actually questioning that. A NOP *has* to take time (the
>>> architecture prevents implementations from discaring it) whereas a static,
>>> unconditional branch will likely be discarded early on by CPUs with even
>>> simple branch prediction logic.
>> I naively thought "NOP" is cheaper than a "B" :(
>> Will use a "B #1" to replace "NOP".
>>
>
> Really?? What's the purpose of a NOP then? It seems to me that an
> architecture is broken if a NOP is slower than a static branch.
>
> -- Steve
Hi Steve and Will,
	I have discussed this with one of our chip design members.
He thinks "NOP" should be better than "B #1" because jump instruction
is one of the most complex instructions for microarchitecture, which
may stall the pipeline. And NOP should be friendly enough for all
microarchitectures. So I will keep the "NOP" version.
Thanks!
Gerry



  reply	other threads:[~2013-10-18  3:31 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-16  3:18 [PATCH v3 0/7] Optimize jump label implementation for ARM64 Jiang Liu
2013-10-16  3:18 ` Jiang Liu
2013-10-16  3:18 ` [PATCH v3 1/7] arm64: introduce basic aarch64 instruction decoding helpers Jiang Liu
2013-10-16  3:18   ` Jiang Liu
2013-10-16 10:51   ` Will Deacon
2013-10-16 10:51     ` Will Deacon
2013-10-16 15:36     ` Jiang Liu
2013-10-16 15:36       ` Jiang Liu
2013-10-16 17:14       ` Jiang Liu
2013-10-16 17:14         ` Jiang Liu
2013-10-17  9:43         ` Will Deacon
2013-10-17  9:43           ` Will Deacon
2013-10-16  3:18 ` [PATCH v3 2/7] arm64: introduce interfaces to hotpatch kernel and module code Jiang Liu
2013-10-16  3:18   ` Jiang Liu
2013-10-16 11:11   ` Will Deacon
2013-10-16 11:11     ` Will Deacon
2013-10-16 16:15     ` Jiang Liu
2013-10-16 16:15       ` Jiang Liu
2013-10-16  3:18 ` [PATCH v3 3/7] arm64: move encode_insn_immediate() from module.c to insn.c Jiang Liu
2013-10-16  3:18   ` Jiang Liu
2013-10-16 11:22   ` Will Deacon
2013-10-16 11:22     ` Will Deacon
2013-10-16 16:33     ` Jiang Liu
2013-10-16 16:33       ` Jiang Liu
2013-10-16  3:18 ` [PATCH v3 4/7] arm64: introduce aarch64_insn_gen_{nop|branch_imm}() helper functions Jiang Liu
2013-10-16  3:18   ` Jiang Liu
2013-10-16  3:18 ` [PATCH v3 5/7] arm64, jump label: detect %c support for ARM64 Jiang Liu
2013-10-16  3:18   ` Jiang Liu
2013-10-16  3:18 ` [PATCH v3 6/7] arm64, jump label: optimize jump label implementation Jiang Liu
2013-10-16  3:18   ` Jiang Liu
2013-10-16 11:46   ` Will Deacon
2013-10-16 11:46     ` Will Deacon
2013-10-16 17:11     ` Jiang Liu
2013-10-16 17:11       ` Jiang Liu
2013-10-17  9:39       ` Will Deacon
2013-10-17  9:39         ` Will Deacon
2013-10-17 14:40         ` Jiang Liu
2013-10-17 14:40           ` Jiang Liu
2013-10-17 15:27           ` Steven Rostedt
2013-10-17 15:27             ` Steven Rostedt
2013-10-18  3:31             ` Jiang Liu (Gerry) [this message]
2013-10-18  3:31               ` Jiang Liu (Gerry)
2013-10-18 10:02               ` Will Deacon
2013-10-18 10:02                 ` Will Deacon
2013-10-16  3:18 ` [PATCH v3 7/7] jump_label: use defined macros instead of hard-coding for better readability Jiang Liu
2013-10-16  3:18   ` Jiang Liu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5260AB8A.2060505@huawei.com \
    --to=jiang.liu@huawei.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.