Re: [RFC PATCH v4 0/3] trace: stack trace deduplication for ftrace ring buffer

[Steven Rostedt]

On Mon,  6 Jul 2026 14:31:54 +0800
Li Pengfei <ljdlns1987@xxxxxxxxx> wrote:

> From: Pengfei Li <lipengfei28@xxxxxxxxxx>
> 
> Hi Steven, Masami,
> 
> Gentle ping on this v4 series now that the 7.2 merge window has settled.
> 
> I'd especially value a quick steer on the two design questions from the
> cover letter, since they shape how I respin:
> 
>   1. Eager vs lazy allocation of the element pool (~8 MB at the default
>      bits=14 when CONFIG_FTRACE_STACKMAP=y, whether or not userspace ever
>      enables the option). Is eager allocation acceptable, or should v5
>      switch to lazy allocation on the first 'echo 1 > options/stackmap'?
> 
>   2. Whether to introduce the stack_map_bin binary interface now, or ship
>      the text stack_map interface first and add the binary export once
>      trace-cmd / libtraceevent integration is designed.
> 
> Happy to respin in either direction. Full series for reference:
> 
>   https://lore.kernel.org/all/20260616064119.438063-1-lipengfei28@xxxxxxxxxx/

Sorry for the late reply. I just started a new job (on 6/15) and spent the
first two weeks focused on that. I'm just catching up now.

Note, I tried out this patch set with function tracing on lock functions:

  trace-cmd start -p function -O stackmap --func-stack -l '*lock*'

And wow! it grows pretty quickly

  # cat /sys/kernel/tracing/stack_map | wc
 326593  708742 10979376

Anyway, I do like the idea and I may even use this to help do user space
stack traces. But I will have to take a deeper dive into it, which I will
hopefully have some time next week to do so. But if not next week, perhaps
within the next month.

I just letting you know that I'm not ignoring you. I'm just a bit behind.

Thanks,

-- Steve