在 2026/1/30 17:30, Masami Hiramatsu (Google) 写道:
On Thu, 29 Jan 2026 15:29:58 -0500
Steven Rostedt <[email protected]> wrote:
On Wed, 28 Jan 2026 19:25:46 -0700
Jens Axboe <[email protected]> wrote:
On Jan 28, 2026, at 5:40 PM, Steven Rostedt <[email protected]> wrote:
Jens,
Can you give me an acked-by on this patch and I can take the series through
my tree.
On phone, hope this works:
Acked-by: Jens Axboe <[email protected]>
Thanks!
Or perhaps this doesn't even need to test the trace_async_init flag and can
always do the work queue? Does blk_trace ever do tracing at boot up? That
is, before user space starts?
Not via the traditonal way of running blktrace.
Masami and Yaxiong,
I've been thinking about this more and I'm not sure we need the
trace_async_init kernel parameter at all. As blktrace should only be
enabled by user space, it can always use the work queue.
For kprobes, if someone is adding a kprobe on the kernel command line, then
they are already specifying that tracing is more important.
Patch 3 already keeps kprobes from being an issue with contention of the
tracing locks, so I don't think it ever needs to use the work queue.
Wouldn't it just be better to remove the trace_async_init and make blktrace
always use the work queue and kprobes never do it (but exit out early if
there were no kprobes registered)?
Yeah, for kprobes event case, that sounds good to me. I think [3/5] is
enough to speed it up if user does not define kprobe events on cmdline.
Thank you,
Agreed.
Hi Jens：
what do you think about this proposal (making blktrace always use the
work queue)?
That is, remove patch 2 and 4 and make this patch always use the work queue.
-- Steve
