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

[Pengfei Li]

On Tue, 08 Sep 2026 10:15:09 +0900 Masami Hiramatsu (Google) <mhiramat@xxxxxxxxxx> wrote:
> BTW, to make it easier for review, can you split the patches in
> several parts? For example, start from a minimum basic functionality
> (just internal stackmap, seq_read, and reset), use it from tracing,
> add stat interface, binary interface, and documents, tools, selftests.
> This makes the series in at least 7 patches, but nicer to focus on
> one thing for each patch.

Agreed, and the split points you list match where the current patches
are doing several things at once. v7 will follow that structure:

   1. internal stackmap: table, element pool, get_id(), create/destroy
   2. text seq_file export and reset
   3. use it from the ftrace stack recording path
   4. stat interface
   5. binary interface
   6. ftrace_stackmap.bits= kernel parameter
   7. documentation
   8. userspace parser
   9. selftest: basic functionality
  10. selftest: reset semantics and binary ABI header
  11. selftest: top-level instance gating

Each patch compiles on its own and does not leave unused helpers or
tracefs files whose backing code has not been added yet. Patches 4 and
5 also carry the stat locking fix and the binary export rework from
your comments on 1/3, so those interfaces arrive in the shape you
asked for rather than being split first and fixed afterwards.

> The patch description is a key area to focus on; if the explanation
> proceeds by saying "add Foo, then add Bar, and so on," those changes
> should likely be split into multiple patches.

That test also flags the current 1/3 and 3/3 accurately. Both of their
descriptions are lists of independent additions, which is why they grew
to 949 and 614 lines. I will use it as the check when writing the v7
descriptions: if a description needs a bullet list of additions, the
patch is still too coarse.

Pengfei