All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frederic Weisbecker <fweisbec@gmail.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: linux-kernel@vger.kernel.org, Ingo Molnar <mingo@elte.hu>,
	Andrew Morton <akpm@linux-foundation.org>,
	Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Subject: Re: [PATCH 1/5] [PATCH 1/5] function-graph/x86: replace unbalanced ret with jmp
Date: Wed, 14 Oct 2009 00:26:45 +0200	[thread overview]
Message-ID: <20091013222644.GB4952@nowhere> (raw)
In-Reply-To: <1255468366.7113.2403.camel@gandalf.stny.rr.com>

On Tue, Oct 13, 2009 at 05:12:46PM -0400, Steven Rostedt wrote:
> On Tue, 2009-10-13 at 23:02 +0200, Frederic Weisbecker wrote:
> > On Tue, Oct 13, 2009 at 04:33:50PM -0400, Steven Rostedt wrote:
> > > From: Steven Rostedt <srostedt@redhat.com>
> > > 
> > > The function graph tracer replaces the return address with a hook to
> > > trace the exit of the function call. This hook will finish by returning
> > > to the real location the function should return to.
> > > 
> > > But the current implementation uses a ret to jump to the real return
> > > location. This causes a imbalance between calls and ret. That is
> > > the original function does a call, the ret goes to the handler
> > > and then the handler does a ret without a matching call.
> > > 
> > > Although the function graph tracer itself still breaks the branch
> > > predictor by replacing the original ret, by using a second ret and
> > > causing an imbalance, it breaks the predictor even more.
> > 
> > 
> > 
> > I have troubles to understand by it breaks the predictor, especially
> > since there is not conditional branch in return_to_handler.
> > But still I don't understand why a ret would break more the branch
> > prediction than a jmp.
> 
> Calls are branch prediction jumps. Which associates the "ret" with the
> call. As it approaches the ret, it starts to receive the code after the
> call.
> 
> But this is stack order. Every call should hit one ret. But with the
> original code, we break this stack. We have one call and two rets. Which
> means that the branch prediction will also get messed up with the
> previous stored call.


Oh, ok I got it.
Thanks.


  reply	other threads:[~2009-10-13 22:27 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-13 20:33 [PATCH 0/5] [GIT PULL][2.6.33] tracing: various updates Steven Rostedt
2009-10-13 20:33 ` [PATCH 1/5] [PATCH 1/5] function-graph/x86: replace unbalanced ret with jmp Steven Rostedt
2009-10-13 20:47   ` Mathieu Desnoyers
2009-10-13 21:10     ` Steven Rostedt
2009-10-13 21:21       ` Mathieu Desnoyers
2009-10-13 21:26         ` Steven Rostedt
2009-10-13 22:32           ` Mathieu Desnoyers
2009-10-13 21:02   ` Frederic Weisbecker
2009-10-13 21:12     ` Steven Rostedt
2009-10-13 22:26       ` Frederic Weisbecker [this message]
2009-10-14  6:58   ` [tip:tracing/core] function-graph/x86: Replace " tip-bot for Steven Rostedt
2009-10-13 20:33 ` [PATCH 2/5] [PATCH 2/5] tracing: export symbols for kernel lock tracepoints Steven Rostedt
2009-10-13 20:43   ` Frederic Weisbecker
2009-10-13 21:14     ` Steven Rostedt
2009-10-13 20:33 ` [PATCH 3/5] [PATCH 3/5] tracing: support multiple pids in set_pid_ftrace file Steven Rostedt
2009-10-14  6:58   ` [tip:tracing/core] tracing: Support " tip-bot for jolsa@redhat.com
2009-10-13 20:33 ` [PATCH 4/5] [PATCH 4/5] tracing: enable records during the module load Steven Rostedt
2009-10-14  6:59   ` [tip:tracing/core] tracing: Enable " tip-bot for Jiri Olsa
2009-10-13 20:33 ` [PATCH 5/5] [PATCH 5/5] tracing: enabling "__cold" functions Steven Rostedt
2009-10-14  6:59   ` [tip:tracing/core] tracing: Enable " tip-bot for Jiri Olsa

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=20091013222644.GB4952@nowhere \
    --to=fweisbec@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@polymtl.ca \
    --cc=mingo@elte.hu \
    --cc=rostedt@goodmis.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.