From: Namhyung Kim <namhyung@kernel.org>
To: Michal Pluta <michalpl2003@gmail.com>
Cc: acme@kernel.org, Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
Mark Rutland <mark.rutland@arm.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Jiri Olsa <jolsa@kernel.org>, Ian Rogers <irogers@google.com>,
Adrian Hunter <adrian.hunter@intel.com>,
James Clark <james.clark@linaro.org>,
linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/5] perf symbol: Speed up demangling of long Rust symbols
Date: Tue, 6 Oct 2026 13:10:55 -0700 [thread overview]
Message-ID: <asVVzyLvtkAnILEr@google.com> (raw)
In-Reply-To: <20260928010227.1903673-1-michalpl2003@gmail.com>
On Mon, Sep 28, 2026 at 02:02:22AM +0100, Michal Pluta wrote:
> dso__demangle_sym() demangles Rust v0 symbols itself instead of using
> a helper like the other demanglers. When a demangled name doesn't fit
> the buffer, it grows the buffer by a fixed 32 bytes and reformats the
> whole name from scratch. The number of attempts grows with the name's
> length, so the total work is quadratic. Rust programs with deeply
> nested generics can have very long demangled names, and I noticed this
> as real time spent in perf report on perf.data recorded from launching
> Bevy and Typst.
>
> Patch 3 is the actual optimisation, doubling the size of the buffer
> instead. Patch 5 moves the Rust-specific logic into its own function,
> matching how the other demanglers are called. I think the cleanup is
> worthwhile but I understand it comes down to personal taste and the
> patch can be skipped if maintainers would rather keep
> dso__demangle_sym() as is.
>
> I used an LLM to review my patches and find the issues with the
> demangle tests and the unterminated buffer bug.
>
> Testing:
> - 'perf test' passes, including the demangle Java, OCaml and Rust
> suites (patch 3 adds a case for a symbol that exceeds the buffer
> limit).
> - 'perf report' output is unchanged before and after this series on
> every Rust binary I tried it on.
> - Built and tested on x86-64 with a 7.0 kernel.
>
> The series is based on perf-tools-next, commit 0ae6fc78c5ce ("perf
> timechart: Remove the unused use_old_power_events variable").
>
> Michal Pluta (5):
> perf test demangle: Fail when demangling fails
> perf symbol: Don't return an unterminated Rust demangle buffer
> perf symbol: Grow the Rust demangle buffer geometrically
> perf symbol: Shrink the demangled Rust buffer to fit
> perf symbol: Move Rust demangling into its own function
Reviewed-by: Namhyung Kim <namhyung@kernel.org>
Thanks,
Namhyung
>
> tools/perf/tests/demangle-java-test.c | 1 +
> tools/perf/tests/demangle-rust-v0-test.c | 13 +++++
> tools/perf/util/symbol.c | 60 +++++++++++++++---------
> 3 files changed, 52 insertions(+), 22 deletions(-)
>
>
> base-commit: 0ae6fc78c5ce0dfd18d8712a50f0fd4602eff103
> --
> 2.43.0
>
prev parent reply other threads:[~2026-10-06 20:10 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-28 1:02 [PATCH 0/5] perf symbol: Speed up demangling of long Rust symbols Michal Pluta
2026-09-28 1:02 ` [PATCH 1/5] perf test demangle: Fail when demangling fails Michal Pluta
2026-09-28 1:07 ` sashiko-bot
2026-09-28 21:31 ` Ian Rogers
2026-09-28 1:02 ` [PATCH 2/5] perf symbol: Don't return an unterminated Rust demangle buffer Michal Pluta
2026-09-28 1:06 ` sashiko-bot
2026-09-28 21:33 ` Ian Rogers
2026-09-30 17:10 ` Arnaldo Carvalho de Melo
2026-09-28 1:02 ` [PATCH 3/5] perf symbol: Grow the Rust demangle buffer geometrically Michal Pluta
2026-09-28 1:08 ` sashiko-bot
2026-09-28 21:43 ` Ian Rogers
2026-10-06 20:06 ` Namhyung Kim
2026-10-09 2:22 ` Michal Pluta
2026-10-09 20:39 ` Ian Rogers
2026-09-28 1:02 ` [PATCH 4/5] perf symbol: Shrink the demangled Rust buffer to fit Michal Pluta
2026-09-28 1:07 ` sashiko-bot
2026-10-06 20:07 ` Namhyung Kim
2026-09-28 1:02 ` [PATCH 5/5] perf symbol: Move Rust demangling into its own function Michal Pluta
2026-09-28 1:07 ` sashiko-bot
2026-10-06 20:10 ` Namhyung Kim [this message]
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=asVVzyLvtkAnILEr@google.com \
--to=namhyung@kernel.org \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=irogers@google.com \
--cc=james.clark@linaro.org \
--cc=jolsa@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=michalpl2003@gmail.com \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
/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 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.