* Re: [RFC IDEA] ftrace: stack trace deduplication in ring buffer
[not found] <CALd=Voi=jdM027HTUL01iRnsShcD+rRj5zbRczEN_y4qZ8QQVA@mail.gmail.com>
@ 2026-05-13 12:51 ` Steven Rostedt
0 siblings, 0 replies; only message in thread
From: Steven Rostedt @ 2026-05-13 12:51 UTC (permalink / raw)
To: 李鹏飞; +Cc: lipengfei28, linux-trace-devel
On Wed, 13 May 2026 11:55:24 +0800
李鹏飞 <ljdlns1987@gmail.com> wrote:
> My question: is this something you'd consider for upstream ftrace,
> or do you feel this belongs in the eBPF/perf domain? If you're open
> to it, I'll prepare a proper RFC patch series addressing:
Yes, this looks appropriate for the tracefs infrastructure.
> - Pre-allocated bucket pool (no GFP_ATOMIC in trace path)
Have you looked at the tracing_map.c code that handles the histograms
for trace events?
> - Per-trace_array instance support
> - rhashtable or similar proven data structure
> - trace-cmd/libtraceevent plugin for stack_id resolution
If it is a standard format that is not expected to change, then it
could simply go into the libtraceevent core.
Thanks,
-- Steve
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2026-05-13 12:51 UTC | newest]
Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <CALd=Voi=jdM027HTUL01iRnsShcD+rRj5zbRczEN_y4qZ8QQVA@mail.gmail.com>
2026-05-13 12:51 ` [RFC IDEA] ftrace: stack trace deduplication in ring buffer Steven Rostedt
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox