On Mon, 26 Jan 2026 10:56:59 +0800 sunliming <[email protected]> wrote:
> During kernel boot, the setup_boot_kprobe_events() function causes > significant delays, increasing overall startup time. > > The root cause is a lock contention chain: its child function > > enable_boot_kprobe_events() requires the event_mutex, which is already > > held by early_event_add_tracer(). early_event_add_tracer() itself is > blocked Ah, early_event_add_tracer() is called by the work function that sets up tracers (and the event directories within them). > > waiting for the trace_event_sem read-write lock, which is held for an > extended > > period by trace_event_update_all(). trace_event_update_all() is > runing in > > eval_map_work_func() in eval_map_wq. > > On my ARM64 platform machine, the latency can reach around 200ms： > > [ 0.268848] trace_kprobe: try_get_event_mutex > kernel/trace/tracekprobe.c,1902,enable_boot_kprobe_events > [ 0.268849] try down_write > kernel/trace/traceevents.c,4114,early_event_add_tracer > [ 0.482382] done up_write > kernel/trace/trace_events.c,3074,trace_event_eval_update > [ 0.482386] done down_write > kernel/trace/trace_events.c,4116,early_event_add_tracer > [ 0.482868] done up_write > kernel/trace/trace_events.c,4119,early_event_add_tracer > [ 0.482877] trace_kprobe: enable_boot_kprobe_events geted eventmutex > [ 0.482879] trace_kprobe: enable_bootk_probe_events release eventmutex I take it that you are aware of this work, as it comes from someone with the same email domain as you have. https://lore.kernel.org/all/[email protected]/ That is moving the kprobe setup into the same work function. -- Steve
