* 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.