Thread (19 messages) 19 messages, 4 authors, 2026-02-02

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

在 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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help