From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
To: Pengfei Li <ljdlns1987@gmail.com>
Cc: Steven Rostedt <rostedt@goodmis.org>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Mark Rutland <mark.rutland@arm.com>,
Jonathan Corbet <corbet@lwn.net>,
Shuah Khan <skhan@linuxfoundation.org>,
kernel test robot <lkp@intel.com>,
Bo Zhang <zhangbo56@xiaomi.com>,
Pengfei Li <lipengfei28@xiaomi.com>,
linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org,
linux-doc@vger.kernel.org, linux-kselftest@vger.kernel.org
Subject: Re: [RFC PATCH v6 3/3] trace: add documentation, selftest and tooling for stackmap
Date: Tue, 8 Sep 2026 10:35:14 +0900 [thread overview]
Message-ID: <20260908103514.a1c61f51b84b8d67d6f0f511@kernel.org> (raw)
In-Reply-To: <20260903132409.270195-4-lipengfei28@xiaomi.com>
On Thu, 3 Sep 2026 21:24:09 +0800
Pengfei Li <ljdlns1987@gmail.com> wrote:
> Add supporting files for the ftrace stackmap feature:
>
Could you decouple tools/docs/tests in independent patches?
> Documentation/trace/ftrace-stackmap.rst:
> Documentation covering design, usage, tracefs interface, binary
> format, and performance characteristics. Added to the 'Core Tracing
> Frameworks' toctree in Documentation/trace/index.rst. Documents:
> - Reset clears the map and nothing else: the trace buffer is left
> untouched and tracing does not have to be stopped, so <stack_id N>
> records in an already-collected trace can stop resolving after a
> reset. Read the trace out first if the ids need to stay meaningful
> - Boot-time activation via trace_options=stackmap: events use the
> full-stack fallback until the map and required resolver are created
> and the map is published to global_trace.stackmap
> - bits parameter range [10, 18] and worst-case memory usage
> - tracefs file modes (0640 / 0440), with stack_map required and
> stack_map_stat / stack_map_bin treated as auxiliary observability
> nodes whose creation failure does not disable deduplication
> - Best-effort snapshot semantics for stack_map_bin, serialized
> against reset via the reader_sem
> - Counter definitions and stable output: successes counts map operations
> that return a stack ID; drops counts capacity or probe-limit
> failures; success_rate excludes bypasses that never call the map
> and remains present as 0% when both counters are zero
> - Gravestone amplification when the pool is exhausted
>
> tools/testing/selftests/ftrace/test.d/ftrace/stackmap-basic.tc:
> Functional selftest verifying:
> - required stackmap tracefs nodes exist; tests that consume auxiliary
> nodes declare them in '# requires:' and skip if unavailable
> - enabling stackmap + stacktrace produces stack_id events
> - stack_map_stat shows non-zero successes; a nonzero drops count is
> a legitimate by-design fallback and is not treated as failure
> - reset succeeds while tracing is active, since it clears the map
> only and leaves the ring buffer alone
> - reset also clears the map when tracing is stopped
> The test starts and exits with a map reset so a failed run cannot
> leak entries or counters into the next case. It reads trace contents
> BEFORE switching back to the nop tracer (tracer_init()
> unconditionally resets the ring buffer). The function:tracer
> dependency is declared in '# requires:' so ftracetest skips on
> kernels without CONFIG_FUNCTION_TRACER instead of failing spuriously.
If each test has this volume description, it is enough to split those
tests in independent patches.
[...]
> +def main():
> + parser = argparse.ArgumentParser(description='Parse ftrace stack_map_bin')
> + parser.add_argument('file', help='Path to stack_map_bin file')
> + parser.add_argument('--vmlinux', help='Path to vmlinux for symbol resolution')
> + parser.add_argument('--json', action='store_true', help='JSON output')
> + parser.add_argument('--top', type=int, default=0,
> + help='Show only top N stacks by ref_count')
> + args = parser.parse_args()
> +
> + with open(args.file, 'rb') as f:
> + data = f.read()
nit: Can this support input from stdin? If we use this on android,
user may want to do:
adb shell cat /sys/.../stack_map_bin | python3 stackmap_dump.py
instead of pulling the file.
Thanks,
--
Masami Hiramatsu (Google) <mhiramat@kernel.org>
next prev parent reply other threads:[~2026-09-08 1:35 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-03 13:24 [RFC PATCH v6 0/3] trace: stack trace deduplication for ftrace ring buffer Pengfei Li
2026-09-03 13:24 ` [RFC PATCH v6 1/3] trace: add lock-free stackmap for stack trace deduplication Pengfei Li
2026-09-08 1:21 ` Masami Hiramatsu
2026-09-08 3:06 ` Pengfei Li
2026-09-03 13:24 ` [RFC PATCH v6 2/3] trace: integrate stackmap into ftrace stack recording path Pengfei Li
2026-09-03 13:24 ` [RFC PATCH v6 3/3] trace: add documentation, selftest and tooling for stackmap Pengfei Li
2026-09-08 1:35 ` Masami Hiramatsu [this message]
2026-09-08 3:09 ` Pengfei Li
2026-09-08 1:15 ` [RFC PATCH v6 0/3] trace: stack trace deduplication for ftrace ring buffer Masami Hiramatsu
2026-09-08 2:55 ` Pengfei Li
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260908103514.a1c61f51b84b8d67d6f0f511@kernel.org \
--to=mhiramat@kernel.org \
--cc=corbet@lwn.net \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=lipengfei28@xiaomi.com \
--cc=ljdlns1987@gmail.com \
--cc=lkp@intel.com \
--cc=mark.rutland@arm.com \
--cc=mathieu.desnoyers@efficios.com \
--cc=rostedt@goodmis.org \
--cc=skhan@linuxfoundation.org \
--cc=zhangbo56@xiaomi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®