All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: sunliming@linux.dev
Cc: mhiramat@kernel.org, mathieu.desnoyers@efficios.com,
	linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org,
	sunliming <sunliming@kylinos.cn>
Subject: Re: [PATCH] tracing: kprobe-event: Return directly when dyn_event_list is empty
Date: Sat, 24 Jan 2026 12:02:33 -0500	[thread overview]
Message-ID: <20260124120233.17926a82@robin> (raw)
In-Reply-To: <20260123013641.23066-1-sunliming@linux.dev>

On Fri, 23 Jan 2026 09:36:41 +0800
sunliming@linux.dev wrote:

> From: sunliming <sunliming@kylinos.cn>
> 
> In enable_boot_kprobe_events(), it returns directly when dyn_event_list is
> empty, thereby reducing the function's execution time. This function may
> otherwise wait for the event_mutex lock for tens of milliseconds on certain
> machines, which is unnecessary when dyn_event_list is empty.

Have you measured this?

I'm curious as to what may be holding the event_mutex at this time.
This is called by the initcall functions which are currently all
serialized. Any conflict would have to be caused by a worker or kthread
and not another initcall callback.

I'm not against the patch, I just want to understand more about it.

> 
> Signed-off-by: sunliming <sunliming@kylinos.cn>
> ---
>  kernel/trace/trace_kprobe.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
> index 9953506370a5..d89a403c99d4 100644
> --- a/kernel/trace/trace_kprobe.c
> +++ b/kernel/trace/trace_kprobe.c
> @@ -1982,6 +1982,9 @@ static __init void enable_boot_kprobe_events(void)
>  	struct trace_kprobe *tk;
>  	struct dyn_event *pos;
>  
> +	if (list_empty(&dyn_event_list))
> +		return;

The above should definitely have a comment or we should wrap that with
another macro because the above is assuming that
for_each_trace_kprobe() uses dyn_event_list. If that ever changes in
the future, this will be broken.

Perhaps we should add a:

	if (trace_kprobe_list_empty())
		return;

?

-- Steve



> +
>  	guard(mutex)(&event_mutex);
>  	for_each_trace_kprobe(tk, pos) {
>  		list_for_each_entry(file, &tr->events, list)


  reply	other threads:[~2026-01-24 17:02 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-23  1:36 [PATCH] tracing: kprobe-event: Return directly when dyn_event_list is empty sunliming
2026-01-24 17:02 ` Steven Rostedt [this message]
     [not found]   ` <01b1d5a3-8be0-4d9a-45d4-4da7c3edf746@linux.dev>
2026-01-26  4:21     ` Steven Rostedt
     [not found]       ` <78dbbd83-8de3-2031-6db7-036d0d8c11c5@linux.dev>
2026-01-26 14:38         ` 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=20260124120233.17926a82@robin \
    --to=rostedt@goodmis.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mhiramat@kernel.org \
    --cc=sunliming@kylinos.cn \
    --cc=sunliming@linux.dev \
    /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.