public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
From: Andi Kleen <andi@firstfloor.org>
To: Masami Hiramatsu <mhiramat@redhat.com>
Cc: Ingo Molnar <mingo@elte.hu>,
		  Ananth N Mavinakayanahalli <ananth@in.ibm.com>,
		  lkml<linux-kernel@vger.kernel.org>,
		  "H. Peter Anvin" <hpa@zytor.com>,
		  Frederic Weisbecker <fweisbec@gmail.com>,
		  Jim Keniston <jkenisto@us.ibm.com>,
		  Srikar Dronamraju <srikar@linux.vnet.ibm.com>,
		  Christoph Hellwig <hch@infradead.org>,
		  Steven Rostedt <rostedt@goodmis.org>,
		  Anders Kaseorg <andersk@ksplice.com>,
		  Tim Abbott <tabbott@ksplice.com>,
		  systemtap<systemtap@sources.redhat.com>,
		  DLE<dle-develop@lists.sourceforge.net>
Subject: Re: [RFC][ PATCH -tip v2 0/7] kprobes: Kprobes jump optimization support
Date: Tue, 23 Jun 2009 12:09:00 -0000	[thread overview]
Message-ID: <87vdmn179n.fsf@basil.nowhere.org> (raw)
In-Reply-To: <20090622212255.5384.53732.stgit@localhost.localdomain> (Masami Hiramatsu's message of "Mon, 22 Jun 2009 17:22:55 -0400")

Masami Hiramatsu <mhiramat@redhat.com> writes:
>
> The gcc's crossjumping unifies equivalent code by inserting indirect
> jumps which jump into other function body. It is hard to know to where
> these jumps jump, so I decided to disable it when setting
> CONFIG_OPTPROBES=y.

That sounds quite bad. Tail call optimization is an important optimization
that especially on kernel style code (lots of indirect pointers
and sometimes deep call chains) is very useful.  It would be quite
sad if production kernels would lose that optimization.

Also tail calls in C should always jump directly to another function,
so they shouldn't be particularly complex to manage.

> I also decided not to optimize probes when it is in functions which
> will cause exceptions, because the exception in the kernel will jump
> to a fixup code and the fixup code jumps back to the middle of the
> same function body.

Note that not only exceptions do that, there are a few other cases
where jumps in and out of out of line sections happen. You might
need a more general mechanism to detect this.

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only.

  parent reply	other threads:[~2009-06-23 12:09 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-22 21:20 Masami Hiramatsu
2009-06-22 21:20 ` [RFC][ PATCH -tip v2 7/7] kprobes: add documents of jump optimization Masami Hiramatsu
2009-06-22 21:20 ` [RFC][ PATCH -tip v2 3/7] Kbuild: disable gcc crossjumping Masami Hiramatsu
2009-06-27 20:13   ` Steven Rostedt
2009-07-17 20:28     ` Sam Ravnborg
2009-07-17 21:12       ` Masami Hiramatsu
2009-07-17 21:14         ` Masami Hiramatsu
2009-07-17 21:19         ` Sam Ravnborg
2009-06-22 21:20 ` [RFC][ PATCH -tip v2 2/7] kprobes: introducing generic insn_slot framework Masami Hiramatsu
2009-06-27 20:09   ` Steven Rostedt
2009-06-29 21:06     ` Masami Hiramatsu
2009-06-22 21:20 ` [RFC][ PATCH -tip v2 1/7] kprobes: use list instead of hlist for insn_pages Masami Hiramatsu
2009-06-22 21:20 ` [RFC][ PATCH -tip v2 6/7] kprobes: x86: support kprobes jump optimization on x86 Masami Hiramatsu
2009-06-22 21:47 ` [RFC][ PATCH -tip v2 5/7] kprobes: x86: cleanup save/restore registers Masami Hiramatsu
2009-06-22 21:47 ` [RFC][ PATCH -tip v2 4/7] kprobes: kprobes jump optimization core Masami Hiramatsu
2009-06-23 12:58   ` Srikar Dronamraju
2009-06-23 13:10     ` Masami Hiramatsu
2009-06-23 11:43 ` [RFC][ PATCH -tip v2 0/7] kprobes: Kprobes jump optimization support Ingo Molnar
2009-06-23 14:05   ` Masami Hiramatsu
2009-06-23 19:40     ` Ingo Molnar
2009-06-23 21:52       ` Masami Hiramatsu
2009-06-23 22:05         ` Masami Hiramatsu
2009-06-23 12:09 ` Andi Kleen [this message]
2009-06-23 13:49   ` Masami Hiramatsu
2009-06-23 16:35     ` Andi Kleen
2009-06-23 17:26       ` Masami Hiramatsu
2009-06-23 20:37         ` Andi Kleen
2009-06-23 20:46           ` Masami Hiramatsu
2009-06-26 23:17           ` Masami Hiramatsu

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=87vdmn179n.fsf@basil.nowhere.org \
    --to=andi@firstfloor.org \
    --cc=ananth@in.ibm.com \
    --cc=andersk@ksplice.com \
    --cc=dle-develop@lists.sourceforge.net \
    --cc=fweisbec@gmail.com \
    --cc=hch@infradead.org \
    --cc=hpa@zytor.com \
    --cc=jkenisto@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhiramat@redhat.com \
    --cc=mingo@elte.hu \
    --cc=rostedt@goodmis.org \
    --cc=srikar@linux.vnet.ibm.com \
    --cc=systemtap@sources.redhat.com \
    --cc=tabbott@ksplice.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).