[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20260126024033.290136-1-tianyaxiong@kylinos.cn>
Date: Mon, 26 Jan 2026 10:40:33 +0800
From: Yaxiong Tian <tianyaxiong@...inos.cn>
To: rostedt@...dmis.org,
axboe@...nel.dk,
mhiramat@...nel.org,
mathieu.desnoyers@...icios.com
Cc: linux-block@...r.kernel.org,
linux-kernel@...r.kernel.org,
linux-trace-kernel@...r.kernel.org,
Yaxiong Tian <tianyaxiong@...inos.cn>
Subject: [PATCH v2 0/3] Tracing: Accelerate Kernel Boot by Asynchronizing
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.
To resolve this issue, I rename `eval_map_wq` and export it 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.
---
Changes in v2:
- Rename eval_map_wq to trace_init_wq.
Yaxiong Tian (3):
tracing: Rename `eval_map_wq` and export it for asynchronous use by
other modules
tracing/kprobes: Make setup_boot_kprobe_events() asynchronous
blktrace: Make init_blk_tracer() asynchronous
kernel/trace/blktrace.c | 23 ++++++++++++++++++++++-
kernel/trace/trace.c | 18 +++++++++---------
kernel/trace/trace.h | 2 ++
kernel/trace/trace_kprobe.c | 14 +++++++++++++-
4 files changed, 46 insertions(+), 11 deletions(-)
--
2.25.1
Powered by blists - more mailing lists