Re: [PATCH v13 00/18] unwind_deferred: Implement sframe handling

[Namhyung Kim]

Hello,

On Mon, Feb 09, 2026 at 06:07:59PM +0100, Jens Remus wrote:
> On 2/5/2026 7:54 PM, Steven Rostedt wrote:
> > On Thu, 5 Feb 2026 10:26:10 -0800
> > Namhyung Kim <namhyung@xxxxxxxxxx> wrote:
> > 
> >>> Namhyung Kim's related perf tools deferred callchain support can be used
> >>> for testing ("perf record --call-graph fp,defer" and "perf report/script").  
> >>
> >> Is it possible for users to choose the unwinder - frame pointer or
> >> SFrame at runtime?  I feel like the option should be
> >> "--call-graph sframe,defer" or just "--call-graph sframe" if it always
> >> uses deferred unwinding.
> > 
> > Currently no, and I'm not sure we want that do we? The idea is to use the
> > best option that is available. Why use frame pointers if sframe is
> > available and it's being called with defer?
> > 
> > If there's no defer, then sframes are not available, so it defaults to the
> > best option available (which will likely be frame pointers).

Users (me, at least) may want to compare stacktraces from FP and SFrame?

> 
> Maybe it would make sense not to "overload" the perf record option
> "--call-graph fp,defer" and use it for all deferred unwinding methods.
> 
> What about "--call-graph defer", "--call-graph any,defer", or
> "--call-graph *,defer"?

Sounds better.  But I think it cannot enforce "--call-graph fp,defer" to
use frame pointers when SFrame is available.. Hmm.

Thanks,
Namhyung