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>
next prev 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).