linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Ingo Molnar <mingo@kernel.org>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	systemtap@sourceware.org, linux-kernel@vger.kernel.org,
	Alban Crequy <alban.crequy@gmail.com>,
	Alban Crequy <alban@kinvolk.io>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "H . Peter Anvin" <hpa@zytor.com>,
	Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>,
	Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>,
	"David S . Miller" <davem@davemloft.net>
Subject: Re: [RFC PATCH -tip 0/2] kprobes: A trial to reuse graph-tracer's return stack for kretprobe
Date: Wed, 24 Jan 2018 12:04:55 -0500	[thread overview]
Message-ID: <20180124120455.249ffc70@vmware.local.home> (raw)
In-Reply-To: <150332999488.7343.4502723000922707699.stgit@devbox>


Hi Masami,

I just came across this patch set (buried deep in my INBOX). Are you
still doing anything with this?

-- Steve


On Tue, 22 Aug 2017 00:40:05 +0900
Masami Hiramatsu <mhiramat@kernel.org> wrote:

> Hello,
> 
> Here is a feasible study patch to use function_graph
> tracer's per-thread return stack for storing kretprobe
> return address as fast path.
> 
> Currently kretprobe has own instance hash-list for storing
> return address. However, it introduces a spin-lock for
> hash list entry and compel users to estimate how many
> probes run concurrently (and set it to kretprobe->maxactive).
> 
> To solve this issue, this reuses function_graph's per-thread
> ret_stack for kretprobes as fast path instead of using its
> hash-list if possible. Note that if the kretprobe has
> custom entry_handler and store data in kretprobe_instance,
> we can not use the fast path, since current per-thread
> return stack is fixed size. (This feature is used by some
> systemtap scripts)
> 
> This series also includes showing missed count of
> kretprobes via ftrace's kprobe_profile interface, which
> had been posted in this March. That is required for
> below test case. (without that, we can not see any
> kretprobe miss count)
> 
> Usage
> =====
> Note that this is just a feasibility study code, and since
> the per-thread ret_stack is initialized only when the
> function_graph tracer is enabled, you have to following
> operation to enable it.
> 
>  # echo '*' > <tracefs>/set_graph_notrace
>  # echo function_graph > <tracefs>/current_tracer
> 
> After that, try to add an kretprobe event with just 1
> instance (anyway we don't use it).
> 
>  # echo r1 vfs_write > <tracefs>/kprobe_events
>  # echo 1 > <tracefs>/events/kprobes/enable
> 
> And run "yes" command concurrently.
> 
>  # for i in {0..31}; do yes > /dev/null & done
>  # cat <tracefs>/kprobe_profile
>   r_vfs_write_0                      4756473               0
> 
> Then you will see the error count (the last column) is zero.
> Currently, this feature is disabled when the function graph
> tracer is stopped, so if you set nop tracer as below,
> 
>  # echo nop > <tracefs>/current_tracer
> 
> Then you'll see the error count is increasing.
> 
>  # cat <tracefs>/kprobe_profile
>   r_vfs_write_0                      7663462          238537
> 
> This may gain the performance of kretprobe, but I haven't
> benchmark it yet.
> 
> 
> TODO
> ====
> This is just a feasible study code, I haven't tested it
> deeper. It may still have some bugs. Anyway, if it is good,
> I would like to split the per-thread return stack code
> from ftrace, and make it a new generic feature (e.g. 
> CONFIG_THERAD_RETURN_STACK) so that both kprobes and
> ftrace can share it. It may also move return-stack
> allocation as direct call instead of event handler.
> 
> Any comment?
> 
> Thank you,
> 
> ---
> 
> Masami Hiramatsu (2):
>       trace: kprobes: Show sum of probe/retprobe nmissed count
>       kprobes/x86: Use graph_tracer's per-thread return stack for kretprobe
> 
> 
>  arch/x86/kernel/kprobes/core.c       |   95 ++++++++++++++++++++++++++++++++++
>  include/linux/ftrace.h               |    3 +
>  kernel/kprobes.c                     |   11 ++++
>  kernel/trace/trace_functions_graph.c |    5 +-
>  kernel/trace/trace_kprobe.c          |    2 -
>  5 files changed, 112 insertions(+), 4 deletions(-)
> 
> --
> Masami Hiramatsu (Linaro) <mhiramat@kernel.org>

  parent reply	other threads:[~2018-01-24 17:05 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-21 15:40 [RFC PATCH -tip 0/2] kprobes: A trial to reuse graph-tracer's return stack for kretprobe Masami Hiramatsu
2017-08-21 15:41 ` [RFC PATCH -tip 1/2] trace: kprobes: Show sum of probe/retprobe nmissed count Masami Hiramatsu
2017-08-21 15:42 ` [RFC PATCH -tip 2/2] kprobes/x86: Use graph_tracer's per-thread return stack for kretprobe Masami Hiramatsu
2018-01-24 17:04 ` Steven Rostedt [this message]
2018-01-25  1:49   ` [RFC PATCH -tip 0/2] kprobes: A trial to reuse graph-tracer's " 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=20180124120455.249ffc70@vmware.local.home \
    --to=rostedt@goodmis.org \
    --cc=alban.crequy@gmail.com \
    --cc=alban@kinvolk.io \
    --cc=ananth@linux.vnet.ibm.com \
    --cc=anil.s.keshavamurthy@intel.com \
    --cc=davem@davemloft.net \
    --cc=fweisbec@gmail.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhiramat@kernel.org \
    --cc=mingo@kernel.org \
    --cc=mingo@redhat.com \
    --cc=systemtap@sourceware.org \
    --cc=tglx@linutronix.de \
    /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 NNTP newsgroup(s).