From: "H. Peter Anvin" <hpa@zytor.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>,
linux-kernel@vger.kernel.org, Ingo Molnar <mingo@elte.hu>,
Andrew Morton <akpm@linux-foundation.org>,
Thomas Gleixner <tglx@linutronix.de>,
Frederic Weisbecker <fweisbec@gmail.com>,
yrl.pp-manager.tt@hitachi.com
Subject: Re: [RFC][PATCH 2/4 v4] ftrace/x86: Add save_regs for i386 function calls
Date: Thu, 19 Jul 2012 16:07:15 -0700 [thread overview]
Message-ID: <50089323.6050203@zytor.com> (raw)
In-Reply-To: <1342739063.12353.82.camel@gandalf.stny.rr.com>
On 07/19/2012 04:04 PM, Steven Rostedt wrote:
> On Thu, 2012-07-19 at 15:53 -0700, H. Peter Anvin wrote:
>
>> lea is not typically faster than add, but in the case of Atom, it is
>> done in an earlier pipeline stage (AGU instead of ALU) which means lea
>> is faster if its inputs are already available as address expressions and
>> is consumed by address expressions; the goal is to avoid the ALU->AGU
>> forwarding latency.
>
> Well, the question is, which is faster:
>
> lea 8(%esp), %esp
> addl $8, %esp
>
> Basically, all we want to do is add 8 to the stack pointer. And this is
> for the x86_32 version of whatever hardware is in use.
>
What I'm telling you is that it depends on the context.
An address expression needs to be ready in the AGU; a piece of data
comes from the ALU. Whenever something moves from the ALU to the AGU,
there is a penalty. There is no penalty to move from the AGU to the
ALU, since the ALU is in a later stage.
I *believe* the stack adjustments push/pop are done in the AGU, but I
have to double-check.
-hpa
next prev parent reply other threads:[~2012-07-19 23:07 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-11 19:50 [RFC][PATCH 0/4 v4] ftrace/kprobes: Setting up ftrace for kprobes Steven Rostedt
2012-07-11 19:50 ` [RFC][PATCH 1/4 v4] ftrace/x86: Add separate function to save regs Steven Rostedt
2012-07-12 12:12 ` Masami Hiramatsu
2012-07-11 19:50 ` [RFC][PATCH 2/4 v4] ftrace/x86: Add save_regs for i386 function calls Steven Rostedt
2012-07-12 12:39 ` Masami Hiramatsu
2012-07-12 15:53 ` Steven Rostedt
2012-07-13 18:47 ` Steven Rostedt
2012-07-17 2:08 ` Masami Hiramatsu
2012-07-17 3:05 ` Steven Rostedt
2012-07-17 3:13 ` Masami Hiramatsu
2012-07-18 15:59 ` Steven Rostedt
2012-07-19 2:20 ` Masami Hiramatsu
2012-07-19 12:52 ` Steven Rostedt
2012-07-19 12:58 ` Steven Rostedt
2012-07-19 22:53 ` H. Peter Anvin
2012-07-19 23:04 ` Steven Rostedt
2012-07-19 23:07 ` H. Peter Anvin [this message]
2012-07-20 1:27 ` Steven Rostedt
2012-07-19 18:24 ` Steven Rostedt
2012-08-21 15:03 ` [tip:perf/core] ftrace/x86_32: Simplify parameter setup for ftrace_regs_caller tip-bot for Uros Bizjak
2012-07-11 19:50 ` [RFC][PATCH 3/4 v4] ftrace/x86: Remove function_trace_stop check from graph caller Steven Rostedt
2012-08-21 15:04 ` [tip:perf/core] " tip-bot for Steven Rostedt
2012-07-11 19:50 ` [RFC][PATCH 4/4 v4] ftrace/x86_64: Add recursion protection inside mcount caller Steven Rostedt
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=50089323.6050203@zytor.com \
--to=hpa@zytor.com \
--cc=akpm@linux-foundation.org \
--cc=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=masami.hiramatsu.pt@hitachi.com \
--cc=mingo@elte.hu \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=yrl.pp-manager.tt@hitachi.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome