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: 39+ 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
2025-01-12 5:26 ` [PATCH] fgraph: Move trace_clock_local() for return time to function_graph tracer Masami Hiramatsu (Google)
2025-01-14 0:54 ` Steven Rostedt
2025-01-14 1:18 ` Masami Hiramatsu
2025-01-14 15:05 ` 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=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 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.