On Fri, Nov 14, 2025 at 01:30:09PM -0500, Steven Rostedt wrote: > On Fri, 14 Nov 2025 10:09:26 -0800 > Ian Rogers <[email protected]> wrote: > > > Just to be clear. I don't think the behavior of using frame pointers > > should change. Deferral has downsides, for example: > > > > $ perf record -g -a sleep 1 > > The biggest advantage of the deferred callstack is that there's much less > duplication of data in the ring buffer. Especially when you have deep > stacks and long system calls. > > Now, if we have frame pointers enabled, we could possibly add a feature to > the deferred unwinder where it could try to do the deferred immediately and > if it faults it then waits until going back to user space.
This would be great if it can share the callstack with later samples before going to user space. > This means that > the frame pointer version should work (unless the user space stack was > swapped out). > > > > > Without deferral kernel stack traces will contain both kernel and user > > traces. With deferral the user stack trace is only generated when the > > system call returns and so there is a chance for kernel stack traces > > to be missing their user part. An obvious behavioral change. Right, this is one of my concerns too. For system-wide profiling, the chances are high it can have some tasks sleeping in the kernel and perf finishes the profiling before they return to user space. Thanks, Namhyung > > I think > > for what you are doing here we can have an option something like: > > > > $ perf record --call-graph fp-deferred -a sleep 1 > > I would be OK with this but I would prefer a much shorter name. Adding 20 > characters to the command line will likely keep people from using it. > > -- Steve
