mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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>

  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®