On Thu, Oct 23, 2025 at 12:40:57PM -0400, Steven Rostedt wrote: > On Thu, 23 Oct 2025 17:00:02 +0200 > Peter Zijlstra <[email protected]> wrote: > > > +/* Deferred unwinding callback for task specific events */ > > +static void perf_unwind_deferred_callback(struct unwind_work *work, > > + struct unwind_stacktrace *trace, u64 > > cookie) > > +{ > > + struct perf_callchain_deferred_event deferred_event = { > > + .trace = trace, > > + .event = { > > + .header = { > > + .type = PERF_RECORD_CALLCHAIN_DEFERRED, > > + .misc = PERF_RECORD_MISC_USER, > > + .size = sizeof(deferred_event.event) + > > + (trace->nr * sizeof(u64)), > > + }, > > + .cookie = cookie, > > + .nr = trace->nr, > > + }, > > + }; > > + > > + perf_iterate_sb(perf_callchain_deferred_output, &deferred_event, NULL); > > +} > > + > > So "perf_iterate_sb()" was the key point I was missing. I'm guessing it's > basically a demultiplexer that distributes events to all the requestors?
A superset. Basically every event in the relevant context that 'wants' it. It is what we use for all traditional side-band events (hence the _sb naming) like mmap, task creation/exit, etc. I was under the impression the perf tool would create one software dummy event to listen specifically for these events per buffer, but alas, when I looked at the tool this does not appear to be the case. As a result it is possible to receive these events multiple times. And since that is a problem that needs to be solved anyway, I didn't think it 'relevant' in this case. > If I had know this, I would have done it completely different. I did do mention it here: https://lkml.kernel.org/r/[email protected] Anyway, no worries. Onwards to figuring out WTF the unwinder doesn't seem to terminate properly.
