[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20260129083817.d26c61da3cf274bf37e1b2a0@kernel.org>
Date: Thu, 29 Jan 2026 08:38:17 +0900
From: Masami Hiramatsu (Google) <mhiramat@...nel.org>
To: Yaxiong Tian <tianyaxiong@...inos.cn>
Cc: rostedt@...dmis.org, axboe@...nel.dk, mathieu.desnoyers@...icios.com,
corbet@....net, skhan@...uxfoundation.org,
linux-trace-kernel@...r.kernel.org, linux-block@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org
Subject: Re: [PATCH v4 0/5] Tracing: Accelerate Kernel Boot by
Asynchronizing
On Wed, 28 Jan 2026 20:51:17 +0800
Yaxiong Tian <tianyaxiong@...inos.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
> other initialization functions under the tracing subsystem that are
> related to this lock to run asynchronously on this workqueue. After this
> optimization, boot time is reduced by approximately 200ms.
>
> Given that asynchronous initialization makes it indeterminate when tracing
> will begin, we introduce the trace_async_init kernel parameter.Asynchronous
> behavior is enabled only when this parameter is explicitly provided.
>
> 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
OK, this series looks good to me.
Acked-by: Masami Hiramatsu (Google) <mhiramat@...nel.org>
for this series.
Thank you,
>
> ---
> 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
>
> Yaxiong Tian (5):
> tracing: Rename `eval_map_wq` and allow other parts of tracing use it
> tracing: add trace_async_init boot parameter
> tracing/kprobes: Skip setup_boot_kprobe_events() when no cmdline event
> tracing/kprobes: Make setup_boot_kprobe_events() asynchronous when
> trace_async_init set
> blktrace: Make init_blk_tracer() asynchronous when trace_async_init
> set
>
> .../admin-guide/kernel-parameters.txt | 8 ++++++
> kernel/trace/blktrace.c | 23 +++++++++++++++-
> kernel/trace/trace.c | 27 ++++++++++++-------
> kernel/trace/trace.h | 2 ++
> kernel/trace/trace_kprobe.c | 18 ++++++++++++-
> 5 files changed, 67 insertions(+), 11 deletions(-)
>
> --
> 2.25.1
>
>
--
Masami Hiramatsu (Google) <mhiramat@...nel.org>
Powered by blists - more mailing lists