From: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
To: Andi Kleen <andi@firstfloor.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Steven Rostedt <rostedt@goodmis.org>,
Jeremy Fitzhardinge <jeremy@goop.org>,
LKML <linux-kernel@vger.kernel.org>, Ingo Molnar <mingo@elte.hu>,
Thomas Gleixner <tglx@linutronix.de>,
Peter Zijlstra <peterz@infradead.org>,
Andrew Morton <akpm@linux-foundation.org>,
David Miller <davem@davemloft.net>,
Roland McGrath <roland@redhat.com>,
Ulrich Drepper <drepper@redhat.com>,
Rusty Russell <rusty@rustcorp.com.au>,
Gregory Haskins <ghaskins@novell.com>,
Arnaldo Carvalho de Melo <acme@redhat.com>,
"Luis Claudio R. Goncalves" <lclaudio@uudg.org>,
Clark Williams <williams@redhat.com>
Subject: Re: Efficient x86 and x86_64 NOP microbenchmarks
Date: Wed, 13 Aug 2008 15:30:11 -0400 [thread overview]
Message-ID: <20080813193011.GC15547@Krystal> (raw)
In-Reply-To: <20080813184142.GM1366@one.firstfloor.org>
* Andi Kleen (andi@firstfloor.org) wrote:
> > So microbenchmarking this way will probably make some things look
> > unrealistically good.
>
> Must be careful to miss the big picture here.
>
> We have two assumptions here in this thread:
>
> - Normal alternative() nops are relatively infrequent, typically
> in points with enough pipeline bubbles anyways, and it likely doesn't
> matter how they are encode. And also they don't have an issue
> with mult part instructions anyways because they're not patched
> at runtime, so always the best known can be used.
>
> - The one case where nops are very frequent and matter and multipart
> is a problem is with ftrace noping out the call to mcount at runtime
> because that happens on every function entry.
> Even there the overhead is not that big, but at least measurable
> in kernel builds.
>
> Now the numbers have shown that just by not using frame pointer (
> -pg right now implies frame pointer) you can get more benefit
> than what you lose from using non optimal nops.
>
> So for me the best strategy would be to get rid of the frame pointer
> and ignore the nops. This unfortunately would require going away
> from -pg and instead post process gcc output to insert "call mcount"
> manually. But the nice advantage of that is that you could actually
> set up a custom table of callers built in a ELF section and with
> that you don't actually need the runtime patching (which is only
> done currently because there's no global table of mcount calls),
> but could do everything in stop_machine(). Without
> runtime patching you also don't need single part nops.
>
I agree that if frame pointer brings a too big overhead, it should not
be used.
Sorry to ask, I feel I must be missing something, but I'm trying to
figure out where you propose to add the "call mcount" ? In the caller or
in the callee ?
In the caller, I guess it would replace the normal function call, call a
trampoline which would jump to the normal code.
In the callee, as what is currently done with -pg, the callee would have
a call mcount at the beginning of the function.
Or is it a different scheme I don't see ? I am trying to figure out how
you happen to do all that without dynamic code modification and manage
not to hurt performance.
Mathieu
> I think that would be the best option. I especially like it because
> it would prevent forcing frame pointer which seems to be costlier
> than any kinds of nosp.
>
> -Andi
>
--
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
next prev parent reply other threads:[~2008-08-13 19:30 UTC|newest]
Thread overview: 106+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-07 18:20 [PATCH 0/5] ftrace: to kill a daemon Steven Rostedt
2008-08-07 18:20 ` [PATCH 1/5] ftrace: create __mcount_loc section Steven Rostedt
2008-08-07 18:20 ` [PATCH 2/5] ftrace: mcount call site on boot nops core Steven Rostedt
2008-08-07 18:20 ` [PATCH 3/5] ftrace: enable mcount recording for modules Steven Rostedt
2008-08-08 6:43 ` Rusty Russell
2008-08-08 12:51 ` Steven Rostedt
2008-08-07 18:20 ` [PATCH 4/5] ftrace: rebuild everything on change to FTRACE_MCOUNT_RECORD Steven Rostedt
2008-08-07 18:20 ` [PATCH 5/5] ftrace: enable using mcount recording on x86 Steven Rostedt
2008-08-07 18:47 ` [PATCH 0/5] ftrace: to kill a daemon Mathieu Desnoyers
2008-08-07 20:42 ` Steven Rostedt
2008-08-08 17:22 ` Mathieu Desnoyers
2008-08-08 17:36 ` Steven Rostedt
2008-08-08 17:46 ` Mathieu Desnoyers
2008-08-08 18:13 ` Steven Rostedt
2008-08-08 18:15 ` Peter Zijlstra
2008-08-08 18:21 ` Mathieu Desnoyers
2008-08-08 18:41 ` Steven Rostedt
2008-08-08 19:04 ` Linus Torvalds
2008-08-08 19:05 ` Mathieu Desnoyers
2008-08-08 23:38 ` Steven Rostedt
2008-08-09 0:23 ` Andi Kleen
2008-08-09 0:36 ` Steven Rostedt
2008-08-09 0:47 ` Jeremy Fitzhardinge
2008-08-09 0:51 ` Linus Torvalds
2008-08-09 1:25 ` Steven Rostedt
2008-08-13 6:31 ` Mathieu Desnoyers
2008-08-13 15:38 ` Mathieu Desnoyers
2008-08-13 17:52 ` Efficient x86 and x86_64 NOP microbenchmarks Mathieu Desnoyers
2008-08-13 18:27 ` Linus Torvalds
2008-08-13 18:41 ` Andi Kleen
2008-08-13 18:45 ` Avi Kivity
2008-08-13 18:51 ` Andi Kleen
2008-08-13 18:56 ` Avi Kivity
2008-08-13 19:30 ` Mathieu Desnoyers [this message]
2008-08-13 19:37 ` Andi Kleen
2008-08-13 20:01 ` Mathieu Desnoyers
2008-08-13 23:41 ` [RFC PATCH] x86 alternatives : fix LOCK_PREFIX race with preemptible kernel and CPU hotplug Mathieu Desnoyers
2008-08-14 0:01 ` H. Peter Anvin
2008-08-14 1:13 ` Mathieu Desnoyers
2008-08-14 1:22 ` Jeremy Fitzhardinge
2008-08-14 1:26 ` Roland McGrath
2008-08-14 1:49 ` Mathieu Desnoyers
2008-08-14 3:35 ` Jeremy Fitzhardinge
2008-08-14 15:18 ` Mathieu Desnoyers
2008-08-14 16:10 ` Linus Torvalds
2008-08-14 16:13 ` H. Peter Anvin
2008-08-14 16:58 ` Mathieu Desnoyers
2008-08-14 17:05 ` Jeremy Fitzhardinge
2008-08-14 17:30 ` Mathieu Desnoyers
2008-08-14 17:43 ` Jeremy Fitzhardinge
2008-08-14 18:37 ` H. Peter Anvin
2008-08-14 18:53 ` Mathieu Desnoyers
2008-08-14 19:29 ` Jeremy Fitzhardinge
2008-08-14 20:31 ` Mathieu Desnoyers
2008-08-14 20:39 ` H. Peter Anvin
2008-08-14 21:46 ` Jeremy Fitzhardinge
2008-08-14 22:26 ` H. Peter Anvin
2008-08-14 17:17 ` H. Peter Anvin
2008-08-14 18:09 ` Mathieu Desnoyers
2008-08-14 19:49 ` Mathieu Desnoyers
2008-08-14 17:04 ` Jeremy Fitzhardinge
2008-08-14 17:18 ` H. Peter Anvin
2008-08-14 17:28 ` Jeremy Fitzhardinge
2008-08-14 17:31 ` H. Peter Anvin
2008-08-14 17:46 ` Mathieu Desnoyers
2008-08-14 17:49 ` Jeremy Fitzhardinge
2008-08-14 17:55 ` Mathieu Desnoyers
2008-08-14 18:59 ` Gregory Haskins
2008-08-15 21:34 ` Efficient x86 and x86_64 NOP microbenchmarks Steven Rostedt
2008-08-15 21:51 ` Andi Kleen
2008-08-13 19:16 ` Mathieu Desnoyers
2008-08-09 0:51 ` [PATCH 0/5] ftrace: to kill a daemon Steven Rostedt
2008-08-09 0:53 ` Roland McGrath
2008-08-09 1:13 ` Andi Kleen
2008-08-09 1:19 ` Andi Kleen
2008-08-09 1:30 ` Steven Rostedt
2008-08-09 1:55 ` Andi Kleen
2008-08-09 2:03 ` Steven Rostedt
2008-08-09 2:23 ` Andi Kleen
2008-08-09 4:12 ` Steven Rostedt
2008-08-09 0:30 ` Steven Rostedt
2008-08-11 18:21 ` Mathieu Desnoyers
2008-08-11 19:28 ` Steven Rostedt
2008-08-08 19:08 ` Jeremy Fitzhardinge
2008-08-11 2:41 ` Rusty Russell
2008-08-11 12:33 ` Steven Rostedt
2008-08-07 21:11 ` Jeremy Fitzhardinge
2008-08-07 21:29 ` Steven Rostedt
2008-08-07 22:26 ` Roland McGrath
2008-08-08 1:21 ` Steven Rostedt
2008-08-08 1:24 ` Steven Rostedt
2008-08-08 1:56 ` Steven Rostedt
2008-08-08 7:22 ` Peter Zijlstra
2008-08-08 11:31 ` Steven Rostedt
2008-08-08 4:54 ` Sam Ravnborg
2008-08-09 9:48 ` Abhishek Sagar
2008-08-09 13:01 ` Steven Rostedt
2008-08-09 15:01 ` Abhishek Sagar
2008-08-09 15:37 ` Steven Rostedt
2008-08-09 17:14 ` Abhishek Sagar
[not found] <20080813191926.GB15547@Krystal>
2008-08-13 20:00 ` Efficient x86 and x86_64 NOP microbenchmarks Steven Rostedt
2008-08-13 20:06 ` Jeremy Fitzhardinge
2008-08-13 20:34 ` Steven Rostedt
2008-08-13 20:15 ` Andi Kleen
2008-08-13 20:21 ` Linus Torvalds
2008-08-13 20:21 ` 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=20080813193011.GC15547@Krystal \
--to=mathieu.desnoyers@polymtl.ca \
--cc=acme@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=andi@firstfloor.org \
--cc=davem@davemloft.net \
--cc=drepper@redhat.com \
--cc=ghaskins@novell.com \
--cc=jeremy@goop.org \
--cc=lclaudio@uudg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
--cc=roland@redhat.com \
--cc=rostedt@goodmis.org \
--cc=rusty@rustcorp.com.au \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=williams@redhat.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 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.