Re: [PATCH v4 5/5] blktrace: Make init_blk_tracer() asynchronous when trace_async_init set
From: Yaxiong Tian <hidden>
Date: 2026-01-30 04:10:29
Also in:
linux-block, linux-doc, lkml
From: Yaxiong Tian <hidden>
Date: 2026-01-30 04:10:29
Also in:
linux-block, linux-doc, lkml
在 2026/1/30 11:45, Steven Rostedt 写道:
On Thu, 29 Jan 2026 22:31:16 -0500 Steven Rostedt [off-list ref] wrote:quoted
I added the below patch and have this result: kworker/u33:1-79 [002] ..... 1.840855: trace_event_update_all: Start syncing swapper/0-1 [005] ..... 6.045742: trace_eval_sync: sync maps kworker/u33:1-79 [002] ..... 12.289296: trace_event_update_all: Finish syncing swapper/0-1 [005] ..... 12.289387: trace_eval_sync: sync maps complete Which shows that the final initcall waited for the work queue to complete:Switching to printk() gives me the same results: # dmesg |grep sync [ 1.117856] Start syncing [ 4.498360] sync maps [ 11.173304] Finish syncing [ 11.175660] sync maps complete -- Steve
Sorry, yes, no problem. I confirmed that init_blk_tracer() is running properly (when executed sequentially) — if there were an issue, it would have already gotten stuck in a lock. It seems like this might be related to the print buffer. I’ll look into this issue myself. Back to this topic — I don’t object to that proposal. I think each has its own advantages. Let’s see what others think.