From: Jiri Olsa <olsajiri@gmail.com>
To: "Masami Hiramatsu (Google)" <mhiramat@kernel.org>
Cc: Alexei Starovoitov <alexei.starovoitov@gmail.com>,
Steven Rostedt <rostedt@goodmis.org>,
Florent Revest <revest@chromium.org>,
linux-trace-kernel@vger.kernel.org,
LKML <linux-kernel@vger.kernel.org>,
Martin KaFai Lau <martin.lau@linux.dev>,
bpf <bpf@vger.kernel.org>, Alexei Starovoitov <ast@kernel.org>,
Alan Maguire <alan.maguire@oracle.com>,
Mark Rutland <mark.rutland@arm.com>,
linux-arch@vger.kernel.org
Subject: Re: [PATCH v22 00/20] tracing: fprobe: function_graph: Multi-function graph and fprobe on fgraph
Date: Thu, 2 Jan 2025 14:20:58 +0100 [thread overview]
Message-ID: <Z3aSuql3fnXMVMoM@krava> (raw)
In-Reply-To: <173518987627.391279.3307342580035322889.stgit@devnote2>
On Thu, Dec 26, 2024 at 02:11:16PM +0900, Masami Hiramatsu (Google) wrote:
> Hi,
>
> Here is the 22nd version of the series to re-implement the fprobe on
> function-graph tracer. The previous version is;
>
> https://lore.kernel.org/all/173379652547.973433.2311391879173461183.stgit@devnote2/
>
> This version is rebased on v6.13-rc4 with fixes on [3/20] for x86-32 and
> [5/20] for build error.
hi,
I ran the bench and I'm seeing native_sched_clock being used
again kretprobe_multi bench:
5.85% bench [kernel.kallsyms] [k] native_sched_clock
|
---native_sched_clock
sched_clock
|
--5.83%--trace_clock_local
ftrace_return_to_handler
return_to_handler
syscall
bpf_prog_test_run_opts
trigger_producer_batch
start_thread
__GI___clone3
I recall we tried to fix that before with [1] change, but that replaced
later with [2] changes
When I remove the trace_clock_local call in __ftrace_return_to_handler
than the kretprobe-multi gets much faster (see last block below), so it
seems worth to make it optional
there's some decrease in kprobe_multi benchmark compared to base numbers,
which I'm not sure yet why, but other than that it seems ok
base:
kprobe : 12.873 ± 0.011M/s
kprobe-multi : 13.088 ± 0.052M/s
kretprobe : 6.339 ± 0.003M/s
kretprobe-multi: 7.240 ± 0.002M/s
fprobe_on_fgraph:
kprobe : 12.816 ± 0.002M/s
kprobe-multi : 12.126 ± 0.004M/s
kretprobe : 6.305 ± 0.018M/s
kretprobe-multi: 7.740 ± 0.003M/s
removed native_sched_clock call:
kprobe : 12.850 ± 0.006M/s
kprobe-multi : 12.115 ± 0.006M/s
kretprobe : 6.270 ± 0.017M/s
kretprobe-multi: 9.190 ± 0.005M/s
happy new year ;-) thanks,
jirka
[1] https://lore.kernel.org/bpf/172615389864.133222.14452329708227900626.stgit@devnote2/
[2] https://lore.kernel.org/all/20240914214805.779822616@goodmis.org/
>
> Overview
> --------
> This series rewrites the fprobe on this function-graph.
> The purposes of this change are;
>
> 1) Remove dependency of the rethook from fprobe so that we can reduce
> the return hook code and shadow stack.
>
> 2) Make 'ftrace_regs' the common trace interface for the function
> boundary.
>
> 1) Currently we have 2(or 3) different function return hook codes,
> the function-graph tracer and rethook (and legacy kretprobe).
> But since this is redundant and needs double maintenance cost,
> I would like to unify those. From the user's viewpoint, function-
> graph tracer is very useful to grasp the execution path. For this
> purpose, it is hard to use the rethook in the function-graph
> tracer, but the opposite is possible. (Strictly speaking, kretprobe
> can not use it because it requires 'pt_regs' for historical reasons.)
>
> 2) Now the fprobe provides the 'pt_regs' for its handler, but that is
> wrong for the function entry and exit. Moreover, depending on the
> architecture, there is no way to accurately reproduce 'pt_regs'
> outside of interrupt or exception handlers. This means fprobe should
> not use 'pt_regs' because it does not use such exceptions.
> (Conversely, kprobe should use 'pt_regs' because it is an abstract
> interface of the software breakpoint exception.)
>
> This series changes fprobe to use function-graph tracer for tracing
> function entry and exit, instead of mixture of ftrace and rethook.
> Unlike the rethook which is a per-task list of system-wide allocated
> nodes, the function graph's ret_stack is a per-task shadow stack.
> Thus it does not need to set 'nr_maxactive' (which is the number of
> pre-allocated nodes).
> Also the handlers will get the 'ftrace_regs' instead of 'pt_regs'.
> Since eBPF mulit_kprobe/multi_kretprobe events still use 'pt_regs' as
> their register interface, this changes it to convert 'ftrace_regs' to
> 'pt_regs'. Of course this conversion makes an incomplete 'pt_regs',
> so users must access only registers for function parameters or
> return value.
>
> Design
> ------
> Instead of using ftrace's function entry hook directly, the new fprobe
> is built on top of the function-graph's entry and return callbacks
> with 'ftrace_regs'.
>
> Since the fprobe requires access to 'ftrace_regs', the architecture
> must support CONFIG_HAVE_DYNAMIC_FTRACE_WITH_ARGS and
> CONFIG_HAVE_FTRACE_GRAPH_FUNC, which enables to call function-graph
> entry callback with 'ftrace_regs', and also
> CONFIG_HAVE_FUNCTION_GRAPH_FREGS, which passes the ftrace_regs to
> return_to_handler.
>
> All fprobes share a single function-graph ops (means shares a common
> ftrace filter) similar to the kprobe-on-ftrace. This needs another
> layer to find corresponding fprobe in the common function-graph
> callbacks, but has much better scalability, since the number of
> registered function-graph ops is limited.
>
> In the entry callback, the fprobe runs its entry_handler and saves the
> address of 'fprobe' on the function-graph's shadow stack as data. The
> return callback decodes the data to get the 'fprobe' address, and runs
> the exit_handler.
>
> The fprobe introduces two hash-tables, one is for entry callback which
> searches fprobes related to the given function address passed by entry
> callback. The other is for a return callback which checks if the given
> 'fprobe' data structure pointer is still valid. Note that it is
> possible to unregister fprobe before the return callback runs. Thus
> the address validation must be done before using it in the return
> callback.
>
> Download
> --------
> This series can be applied against the v6.13-rc2 kernel.
>
> This series can also be found below branch.
>
> https://git.kernel.org/pub/scm/linux/kernel/git/mhiramat/linux.git/log/?h=topic/fprobe-on-fgraph
>
> Thank you,
>
> ---
>
> Masami Hiramatsu (Google) (19):
> fgraph: Get ftrace recursion lock in function_graph_enter
> fgraph: Pass ftrace_regs to entryfunc
> fgraph: Replace fgraph_ret_regs with ftrace_regs
> fgraph: Pass ftrace_regs to retfunc
> fprobe: Use ftrace_regs in fprobe entry handler
> fprobe: Use ftrace_regs in fprobe exit handler
> tracing: Add ftrace_partial_regs() for converting ftrace_regs to pt_regs
> tracing: Add ftrace_fill_perf_regs() for perf event
> tracing/fprobe: Enable fprobe events with CONFIG_DYNAMIC_FTRACE_WITH_ARGS
> bpf: Enable kprobe_multi feature if CONFIG_FPROBE is enabled
> ftrace: Add CONFIG_HAVE_FTRACE_GRAPH_FUNC
> fprobe: Rewrite fprobe on function-graph tracer
> fprobe: Add fprobe_header encoding feature
> tracing/fprobe: Remove nr_maxactive from fprobe
> selftests: ftrace: Remove obsolate maxactive syntax check
> selftests/ftrace: Add a test case for repeating register/unregister fprobe
> Documentation: probes: Update fprobe on function-graph tracer
> ftrace: Add ftrace_get_symaddr to convert fentry_ip to symaddr
> bpf: Use ftrace_get_symaddr() for kprobe_multi probes
>
> Sven Schnelle (1):
> s390/tracing: Enable HAVE_FTRACE_GRAPH_FUNC
>
>
> Documentation/trace/fprobe.rst | 42 +
> arch/arm64/Kconfig | 2
> arch/arm64/include/asm/Kbuild | 1
> arch/arm64/include/asm/ftrace.h | 51 +-
> arch/arm64/kernel/asm-offsets.c | 12
> arch/arm64/kernel/entry-ftrace.S | 32 +
> arch/arm64/kernel/ftrace.c | 78 ++
> arch/loongarch/Kconfig | 4
> arch/loongarch/include/asm/fprobe.h | 12
> arch/loongarch/include/asm/ftrace.h | 32 -
> arch/loongarch/kernel/asm-offsets.c | 12
> arch/loongarch/kernel/ftrace_dyn.c | 10
> arch/loongarch/kernel/mcount.S | 17 -
> arch/loongarch/kernel/mcount_dyn.S | 14
> arch/powerpc/Kconfig | 1
> arch/powerpc/include/asm/ftrace.h | 13
> arch/powerpc/kernel/trace/ftrace.c | 8
> arch/powerpc/kernel/trace/ftrace_64_pg.c | 16
> arch/riscv/Kconfig | 3
> arch/riscv/include/asm/Kbuild | 1
> arch/riscv/include/asm/ftrace.h | 45 +
> arch/riscv/kernel/ftrace.c | 17 -
> arch/riscv/kernel/mcount.S | 24 -
> arch/s390/Kconfig | 4
> arch/s390/include/asm/fprobe.h | 10
> arch/s390/include/asm/ftrace.h | 37 +
> arch/s390/kernel/asm-offsets.c | 6
> arch/s390/kernel/entry.h | 1
> arch/s390/kernel/ftrace.c | 48 -
> arch/s390/kernel/mcount.S | 23 -
> arch/x86/Kconfig | 4
> arch/x86/include/asm/Kbuild | 1
> arch/x86/include/asm/ftrace.h | 54 +-
> arch/x86/kernel/ftrace.c | 47 +
> arch/x86/kernel/ftrace_32.S | 13
> arch/x86/kernel/ftrace_64.S | 17 -
> include/asm-generic/fprobe.h | 46 +
> include/linux/fprobe.h | 62 +-
> include/linux/ftrace.h | 116 +++
> include/linux/ftrace_regs.h | 2
> kernel/trace/Kconfig | 22 -
> kernel/trace/bpf_trace.c | 28 +
> kernel/trace/fgraph.c | 65 +-
> kernel/trace/fprobe.c | 664 +++++++++++++++-----
> kernel/trace/ftrace.c | 6
> kernel/trace/trace.h | 6
> kernel/trace/trace_fprobe.c | 146 ++--
> kernel/trace/trace_functions_graph.c | 10
> kernel/trace/trace_irqsoff.c | 6
> kernel/trace/trace_probe_tmpl.h | 2
> kernel/trace/trace_sched_wakeup.c | 6
> kernel/trace/trace_selftest.c | 11
> lib/test_fprobe.c | 51 --
> samples/fprobe/fprobe_example.c | 4
> .../test.d/dynevent/add_remove_fprobe_repeat.tc | 19 +
> .../ftrace/test.d/dynevent/fprobe_syntax_errors.tc | 4
> 56 files changed, 1318 insertions(+), 670 deletions(-)
> create mode 100644 arch/loongarch/include/asm/fprobe.h
> create mode 100644 arch/s390/include/asm/fprobe.h
> create mode 100644 include/asm-generic/fprobe.h
> create mode 100644 tools/testing/selftests/ftrace/test.d/dynevent/add_remove_fprobe_repeat.tc
>
> --
> Masami Hiramatsu (Google) <mhiramat@kernel.org>
next prev parent reply other threads:[~2025-01-02 13:21 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-26 5:11 [PATCH v22 00/20] tracing: fprobe: function_graph: Multi-function graph and fprobe on fgraph Masami Hiramatsu (Google)
2024-12-26 5:11 ` [PATCH v22 01/20] fgraph: Get ftrace recursion lock in function_graph_enter Masami Hiramatsu (Google)
2024-12-26 5:11 ` [PATCH v22 02/20] fgraph: Pass ftrace_regs to entryfunc Masami Hiramatsu (Google)
2024-12-26 5:11 ` [PATCH v22 03/20] fgraph: Replace fgraph_ret_regs with ftrace_regs Masami Hiramatsu (Google)
2024-12-26 5:12 ` [PATCH v22 04/20] fgraph: Pass ftrace_regs to retfunc Masami Hiramatsu (Google)
2024-12-26 5:12 ` [PATCH v22 05/20] fprobe: Use ftrace_regs in fprobe entry handler Masami Hiramatsu (Google)
2024-12-26 5:12 ` [PATCH v22 06/20] fprobe: Use ftrace_regs in fprobe exit handler Masami Hiramatsu (Google)
2024-12-26 5:12 ` [PATCH v22 07/20] tracing: Add ftrace_partial_regs() for converting ftrace_regs to pt_regs Masami Hiramatsu (Google)
2024-12-26 5:12 ` [PATCH v22 08/20] tracing: Add ftrace_fill_perf_regs() for perf event Masami Hiramatsu (Google)
2024-12-26 5:13 ` [PATCH v22 09/20] tracing/fprobe: Enable fprobe events with CONFIG_DYNAMIC_FTRACE_WITH_ARGS Masami Hiramatsu (Google)
2024-12-26 5:13 ` [PATCH v22 10/20] bpf: Enable kprobe_multi feature if CONFIG_FPROBE is enabled Masami Hiramatsu (Google)
2024-12-26 5:13 ` [PATCH v22 11/20] ftrace: Add CONFIG_HAVE_FTRACE_GRAPH_FUNC Masami Hiramatsu (Google)
2024-12-26 5:13 ` [PATCH v22 12/20] s390/tracing: Enable HAVE_FTRACE_GRAPH_FUNC Masami Hiramatsu (Google)
2024-12-26 5:13 ` [PATCH v22 13/20] fprobe: Rewrite fprobe on function-graph tracer Masami Hiramatsu (Google)
2024-12-26 5:14 ` [PATCH v22 14/20] fprobe: Add fprobe_header encoding feature Masami Hiramatsu (Google)
2024-12-26 5:14 ` [PATCH v22 15/20] tracing/fprobe: Remove nr_maxactive from fprobe Masami Hiramatsu (Google)
2024-12-26 5:14 ` [PATCH v22 16/20] selftests: ftrace: Remove obsolate maxactive syntax check Masami Hiramatsu (Google)
2024-12-26 5:14 ` [PATCH v22 17/20] selftests/ftrace: Add a test case for repeating register/unregister fprobe Masami Hiramatsu (Google)
2024-12-26 5:15 ` [PATCH v22 18/20] Documentation: probes: Update fprobe on function-graph tracer Masami Hiramatsu (Google)
2024-12-26 5:15 ` [PATCH v22 19/20] ftrace: Add ftrace_get_symaddr to convert fentry_ip to symaddr Masami Hiramatsu (Google)
2025-02-03 21:33 ` Gabriel de Perthuis
2025-02-04 9:19 ` Masami Hiramatsu
2025-02-04 14:19 ` Gabriel de Perthuis
2025-02-06 1:59 ` Masami Hiramatsu
2024-12-26 5:15 ` [PATCH v22 20/20] bpf: Use ftrace_get_symaddr() for kprobe_multi probes Masami Hiramatsu (Google)
2024-12-27 2:23 ` Steven Rostedt
2024-12-27 2:24 ` Steven Rostedt
2024-12-27 15:24 ` Steven Rostedt
2024-12-31 15:48 ` Masami Hiramatsu
2024-12-31 16:00 ` [PATCH v23] " Masami Hiramatsu (Google)
2025-01-02 13:20 ` Jiri Olsa [this message]
2025-01-11 0:04 ` [PATCH v22 00/20] tracing: fprobe: function_graph: Multi-function graph and fprobe on fgraph Andrii Nakryiko
2025-01-14 15:12 ` Jiri Olsa
2025-01-14 19:04 ` Andrii Nakryiko
2025-01-12 4:45 ` 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=Z3aSuql3fnXMVMoM@krava \
--to=olsajiri@gmail.com \
--cc=alan.maguire@oracle.com \
--cc=alexei.starovoitov@gmail.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=martin.lau@linux.dev \
--cc=mhiramat@kernel.org \
--cc=revest@chromium.org \
--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 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).