From: Menglong Dong <menglong.dong@linux.dev>
To: Jiri Olsa <olsajiri@gmail.com>
Cc: Jiri Olsa <olsajiri@gmail.com>,
mhiramat@kernel.org, rostedt@goodmis.org,
mathieu.desnoyers@efficios.com, linux-kernel@vger.kernel.org,
linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org
Subject: Re: [PATCH 2/2] tracing: fprobe: optimization for entry only case
Date: Tue, 23 Sep 2025 21:34:20 +0800 [thread overview]
Message-ID: <5938379.DvuYhMxLoT@7950hx> (raw)
In-Reply-To: <aNKRoKTAmKpafk4F@krava>
On 2025/9/23 20:25, Jiri Olsa wrote:
> On Tue, Sep 23, 2025 at 07:16:55PM +0800, menglong.dong@linux.dev wrote:
> > On 2025/9/23 19:10 Jiri Olsa <olsajiri@gmail.com> write:
> > > On Tue, Sep 23, 2025 at 05:20:01PM +0800, Menglong Dong wrote:
> > > > For now, fgraph is used for the fprobe, even if we need trace the entry
> > > > only. However, the performance of ftrace is better than fgraph, and we
> > > > can use ftrace_ops for this case.
> > > >
> > > > Then performance of kprobe-multi increases from 54M to 69M. Before this
> > > > commit:
> > > >
> > > > $ ./benchs/run_bench_trigger.sh kprobe-multi
> > > > kprobe-multi : 54.663 ± 0.493M/s
> > > >
> > > > After this commit:
> > > >
> > > > $ ./benchs/run_bench_trigger.sh kprobe-multi
> > > > kprobe-multi : 69.447 ± 0.143M/s
> > > >
> > > > Mitigation is disable during the bench testing above.
> > > >
> > > > Signed-off-by: Menglong Dong <dongml2@chinatelecom.cn>
> > > > ---
> > > > kernel/trace/fprobe.c | 88 +++++++++++++++++++++++++++++++++++++++----
> > > > 1 file changed, 81 insertions(+), 7 deletions(-)
> > > >
> > > > diff --git a/kernel/trace/fprobe.c b/kernel/trace/fprobe.c
> > > > index 1785fba367c9..de4ae075548d 100644
> > > > --- a/kernel/trace/fprobe.c
> > > > +++ b/kernel/trace/fprobe.c
> > > > @@ -292,7 +292,7 @@ static int fprobe_fgraph_entry(struct ftrace_graph_ent *trace, struct fgraph_ops
> > > > if (node->addr != func)
> > > > continue;
> > > > fp = READ_ONCE(node->fp);
> > > > - if (fp && !fprobe_disabled(fp))
> > > > + if (fp && !fprobe_disabled(fp) && fp->exit_handler)
> > > > fp->nmissed++;
> > > > }
> > > > return 0;
> > > > @@ -312,11 +312,11 @@ static int fprobe_fgraph_entry(struct ftrace_graph_ent *trace, struct fgraph_ops
> > > > if (node->addr != func)
> > > > continue;
> > > > fp = READ_ONCE(node->fp);
> > > > - if (!fp || fprobe_disabled(fp))
> > > > + if (unlikely(!fp || fprobe_disabled(fp) || !fp->exit_handler))
> > > > continue;
> > > >
> > > > data_size = fp->entry_data_size;
> > > > - if (data_size && fp->exit_handler)
> > > > + if (data_size)
> > > > data = fgraph_data + used + FPROBE_HEADER_SIZE_IN_LONG;
> > > > else
> > > > data = NULL;
> > > > @@ -327,7 +327,7 @@ static int fprobe_fgraph_entry(struct ftrace_graph_ent *trace, struct fgraph_ops
> > > > ret = __fprobe_handler(func, ret_ip, fp, fregs, data);
> > > >
> > > > /* If entry_handler returns !0, nmissed is not counted but skips exit_handler. */
> > > > - if (!ret && fp->exit_handler) {
> > > > + if (!ret) {
> > > > int size_words = SIZE_IN_LONG(data_size);
> > > >
> > > > if (write_fprobe_header(&fgraph_data[used], fp, size_words))
> > > > @@ -384,6 +384,70 @@ static struct fgraph_ops fprobe_graph_ops = {
> > > > };
> > > > static int fprobe_graph_active;
> > > >
> > > > +/* ftrace_ops backend (entry-only) */
> > > > +static void fprobe_ftrace_entry(unsigned long ip, unsigned long parent_ip,
> > > > + struct ftrace_ops *ops, struct ftrace_regs *fregs)
> > > > +{
> > > > + struct fprobe_hlist_node *node;
> > > > + struct rhlist_head *head, *pos;
> > > > + struct fprobe *fp;
> > > > +
> > > > + guard(rcu)();
> > > > + head = rhltable_lookup(&fprobe_ip_table, &ip, fprobe_rht_params);
> > >
> > > hi,
> > > so this is based on yout previous patch, right?
> > > fprobe: use rhltable for fprobe_ip_table
> > >
> > > would be better to mention that.. is there latest version of that somewhere?
> >
> > Yeah, this is based on that version. That patch is applied
> > to: https://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace.git/log/?h=probes%2Ffor-next
> >
> > And I do the testing on that branches.
>
> did you run 'test_progs -t kprobe_multi' ? it silently crashes the
> kernel for me.. attaching config
Hi. I have tested the whole test_progs and it passed.
In fact, your config will panic even without this patch.
Please don't enable CONFIG_X86_KERNEL_IBT, the recursion
of the is_endbr() still exist until this series apply:
tracing: fprobe: Protect return handler from recursion loop
Thanks!
Menglong Dong
>
> jirka
>
>
next prev parent reply other threads:[~2025-09-23 13:34 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-23 9:20 [PATCH 1/2] tracing: fprobe: rename fprobe_entry to fprobe_fgraph_entry Menglong Dong
2025-09-23 9:20 ` [PATCH 2/2] tracing: fprobe: optimization for entry only case Menglong Dong
2025-09-23 11:10 ` Jiri Olsa
2025-09-23 11:16 ` menglong.dong
2025-09-23 12:25 ` Jiri Olsa
2025-09-23 13:34 ` Menglong Dong [this message]
2025-09-23 16:25 ` Jiri Olsa
2025-09-24 0:23 ` Masami Hiramatsu
2025-09-24 1:33 ` menglong.dong
2025-09-23 9:38 ` [PATCH 1/2] tracing: fprobe: rename fprobe_entry to fprobe_fgraph_entry Steven Rostedt
2025-09-23 10:27 ` menglong.dong
2025-09-23 23:07 ` Masami Hiramatsu
2025-09-24 0:17 ` Menglong Dong
2025-09-24 8:13 ` 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=5938379.DvuYhMxLoT@7950hx \
--to=menglong.dong@linux.dev \
--cc=bpf@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mhiramat@kernel.org \
--cc=olsajiri@gmail.com \
--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.