From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
To: Yaxiong Tian <tianyaxiong@kylinos.cn>
Cc: axboe@kernel.dk, rostedt@goodmis.org,
mathieu.desnoyers@efficios.com, linux-block@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org
Subject: Re: [PATCH v5 0/3] Tracing: Accelerate Kernel Boot by Asynchronizing
Date: Wed, 4 Feb 2026 19:15:52 +0900 [thread overview]
Message-ID: <20260204191552.881a00764093cf63557a372a@kernel.org> (raw)
In-Reply-To: <20260204015103.155025-1-tianyaxiong@kylinos.cn>
On Wed, 4 Feb 2026 09:51:03 +0800
Yaxiong Tian <tianyaxiong@kylinos.cn> wrote:
> On my ARM64 platform, I observed that certain tracing module
> initializations run for up to 200ms—for example, init_kprobe_trace().
> Analysis reveals the root cause: the execution flow eval_map_work_func()
> →trace_event_update_with_eval_map()→trace_event_update_all()
> is highly time-consuming. Although this flow is placed in eval_map_wq
> for asynchronous execution, it holds the trace_event_sem lock, causing
> other modules to be blocked either directly or indirectly. Also in
> init_blk_tracer(), this functions require trace_event_sem device_initcall.
>
> To resolve this issue, I rename `eval_map_wq` and make it global and moved
> init_blk_tracer that are related to this lock to run asynchronously on this
> workqueue. Also check for kprobe_event= grub parameter; if not provided,
> init_kprobe_trace() returns directly. After optimization, boot time is
> reduced by approximately 200ms.
>
>
> Based on my analysis and testing, I've identified that only these two
> locations significantly impact timing. Other initcall_* functions do not
> exhibit relevant lock contention.
>
> A brief summary of the test results is as follows:
> Before this PATCHS:
> [ 0.224933] calling init_kprobe_trace+0x0/0xe0 @ 1
> [ 0.455016] initcall init_kprobe_trace+0x0/0xe0 returned 0 after 230080 usecs
>
> Only opt setup_boot_kprobe_events() can see:
> [ 0.258609] calling init_blk_tracer+0x0/0x68 @ 1
> [ 0.454991] initcall init_blk_tracer+0x0/0x68 returned 0 after 196377 usecs
>
> After this PATCHS:
> [ 0.224940] calling init_kprobe_trace+0x0/0xe0 @ 1
> [ 0.224946] initcall init_kprobe_trace+0x0/0xe0 returned 0 after 3 usecs
> skip --------
> [ 0.264835] calling init_blk_tracer+0x0/0x68 @ 1
> [ 0.264841] initcall init_blk_tracer+0x0/0x68 returned 0 after 2 usecs
Looks good to me.
Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Thanks!
>
> ---
> Changes in v2:
> - Rename eval_map_wq to trace_init_wq.
> Changes in v3:
> - Opt PATCH 1/3 commit
> Changes in v4:
> - add trace_async_init boot parameter in patch2
> - add init_kprobe_trace's skip logic in patch3
> - add Suggested-by tag
> - Other synchronous optimizations related to trace_async_init
> https://lore.kernel.org/all/20260128125117.1704853-1-tianyaxiong@kylinos.cn/
> Changes in v5:
> - remove trace_async_init boot parameter (patch2 v4)
> - remove make Make setup_boot_kprobe_events() asynchronous (patch4 v4)
> - Adjusted the patch sequence.
>
>
> Yaxiong Tian (3):
> tracing: Rename `eval_map_wq` and allow other parts of tracing use it
> blktrace: Make init_blk_tracer() asynchronous
> tracing/kprobes: Skip setup_boot_kprobe_events() when no cmdline event
>
> kernel/trace/blktrace.c | 23 ++++++++++++++++++++++-
> kernel/trace/trace.c | 18 +++++++++---------
> kernel/trace/trace.h | 1 +
> kernel/trace/trace_kprobe.c | 4 ++++
> 4 files changed, 36 insertions(+), 10 deletions(-)
>
> --
> 2.25.1
>
>
--
Masami Hiramatsu (Google) <mhiramat@kernel.org>
next prev parent reply other threads:[~2026-02-04 10:15 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-04 1:51 [PATCH v5 0/3] Tracing: Accelerate Kernel Boot by Asynchronizing Yaxiong Tian
2026-02-04 1:53 ` [PATCH v5 1/3] tracing: Rename `eval_map_wq` and allow other parts of tracing use it Yaxiong Tian
2026-02-04 1:53 ` [PATCH v5 2/3] blktrace: Make init_blk_tracer() asynchronous Yaxiong Tian
2026-02-04 1:54 ` [PATCH v5 3/3] tracing/kprobes: Skip setup_boot_kprobe_events() when no cmdline event Yaxiong Tian
2026-02-04 10:15 ` Masami Hiramatsu [this message]
2026-02-06 20:25 ` [PATCH v5 0/3] Tracing: Accelerate Kernel Boot by Asynchronizing 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=20260204191552.881a00764093cf63557a372a@kernel.org \
--to=mhiramat@kernel.org \
--cc=axboe@kernel.dk \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=rostedt@goodmis.org \
--cc=tianyaxiong@kylinos.cn \
/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