在 2026/1/30 04:29, Steven Rostedt 写道:
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.
Hi Steven and Jens:
I've been thinking about this further. If we need to consider the
possibility of non-traditional blktrace usage during the boot phase,
could we perhaps use a grub parameter like 'ftrace=blk' to handle this?
More specifically, we could check this through
the|default_bootup_tracer|mechanism.
+bool __init trace_check_need_bootup_tracer(struct tracer *type)
+{
+ if (!default_bootup_tracer)
+ return false;
+
+ if (strncmp(default_bootup_tracer, type->name, MAX_TRACER_SIZE))
+ return false;
+ else
+ return true;
+}
+
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)?
That is, remove patch 2 and 4 and make this patch always use the work queue.
-- Steve
