linux-kernel - [PATCH v4 0/5] Tracing: Accelerate Kernel Boot by Asynchronizing

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <20260128125117.1704853-1-tianyaxiong@kylinos.cn>
Date: Wed, 28 Jan 2026 20:51:17 +0800
From: Yaxiong Tian <tianyaxiong@...inos.cn>
To: mhiramat@...nel.org,
	rostedt@...dmis.org,
	axboe@...nel.dk,
	mathieu.desnoyers@...icios.com,
	corbet@....net,
	skhan@...uxfoundation.org
Cc: linux-trace-kernel@...r.kernel.org,
	linux-block@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	linux-doc@...r.kernel.org,
	Yaxiong Tian <tianyaxiong@...inos.cn>
Subject: [PATCH v4 0/5] 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. 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

---
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