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, > > That is, remove patch 2 and 4 and make this patch always use the work queue. > > -- Steve -- Masami Hiramatsu (Google) <[email protected]>
