On Tue, 27 May 2025 16:11:30 -0400 Steven Rostedt <[email protected]> wrote:
> On Tue, 27 May 2025 12:11:40 -0400 > Steven Rostedt <[email protected]> wrote: > > > But there just happens to be one scenario where this can legitimately > > happen. That is on a commit_overrun. A commit overrun is when an interrupt > > preempts an event being written to the buffer and then the interrupt adds > > so many new events that it fills and wraps the buffer back to the commit. > > Any new events would then be dropped and be reported as "missed_events". > > I'll probably update the commit log, but the way I triggered this was to run: > > # perf record -o perf-test.dat -a -- trace-cmd record --nosplice -e all -p > function hackbench 50 Hmm, so this runs 3 commands, hackbench, which is traced by trace-cmd, which is traced by perf. > > Which causes perf to trigger a bunch of interrupts while trace-cmd enables > function tracing and all events. This is on a debug kernel that has > lockdep, KASAN and interrupt and preemption disabling events enabled. Ah, that is the full-set of the interrupt and tracing :) Thanks, > > Basically, this causes a lot to be traced in an interrupt. Enough to fill > 1.4 megs of the tracing buffer with events in interrupts before a single > event could be recorded. > > I've never triggered this when those extreme conditions were not there. > > -- Steve -- Masami Hiramatsu (Google) <[email protected]>
