All of lore.kernel.org
 help / color / mirror / Atom feed
From: Namhyung Kim <namhyung@kernel.org>
To: haghdoost@uber.com
Cc: Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	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>,
	Alexei Starovoitov <ast@kernel.org>,
	Andrii Nakryiko <andriin@fb.com>,
	linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 2/4] perf script: Add --max-symbol-bytes to bound ELF symbol memory
Date: Sun, 20 Sep 2026 17:03:16 -0700	[thread overview]
Message-ID: <arB0RCpi9szb5d_R@z2> (raw)
In-Reply-To: <20260919-perf-symbol-memory-send-v2-2-495b8f00ad7c@uber.com>

On Sat, Sep 19, 2026 at 07:33:57PM -0700, Alireza Haghdoost via B4 Relay wrote:
> From: Alireza Haghdoost <haghdoost@uber.com>
> 
> perf script eagerly materializes every ELF symbol into an rb-tree kept
> until process exit. Large profiles can therefore consume substantial
> anonymous memory, causing perf script to be OOM-killed or forcing the
> kernel to reclaim memory from co-located workloads.
> 
> This patch adds --max-symbol-bytes to bound struct symbol allocations.
> Once the budget is reached, the ELF loader stops loading symbols, warns
> once, and lets unresolved addresses appear as [unknown]. This allows
> users to bound the memory footprint upfront and explicitly choose between
> complete symbolization and avoiding unbounded host memory pressure. perf
> record already provides a similar --max-size option to bound disk usage.
> 
> The counter includes every symbol__new() allocation, but this patch
> enforces the limit only in the ELF loader, which is the source of the
> unbounded memory growth addressed here. In this path, reaching the limit
> can safely produce [unknown] symbols. Other loaders currently treat a
> failed symbol allocation as an error. Capping those paths would therefore
> require separate changes whose complexity may outweigh the potential
> memory savings.
> 
> The cap applies to userspace DSOs, vmlinux-as-ELF, and kernel modules.
> Sizes require a B/K/M/G suffix, except that a bare 0 and the default mean
> unlimited. Reservations are atomic so concurrent loaders cannot exceed the
> limit; accounting retains complete name lengths and partial zero-sized
> symbol ranges do not cover omitted addresses.
> 
> Document the option with the code that introduces it and add focused
> accounting and concurrent-reservation tests.
> 
> Signed-off-by: Alireza Haghdoost <haghdoost@uber.com>
> ---
[SNIP] 
> diff --git a/tools/perf/util/symbol.h b/tools/perf/util/symbol.h
> index 46b1649c64fc..f7331edf0b71 100644
> --- a/tools/perf/util/symbol.h
> +++ b/tools/perf/util/symbol.h
> @@ -90,7 +90,7 @@ struct symbol {
>  	u64		start;
>  	u64		end;
>  	/** Length of the string name. */
> -	u16		namelen;
> +	u32		namelen;

Why is this needed?  Do you have symbols with a really long name?
Anyway, it should be a separate change then.

Thanks,
Namhyung


>  	_Atomic uint16_t flags;
>  	/** Architecture specific. Unused except on PPC where it holds st_other. */
>  	u8		arch_sym;
> @@ -227,6 +227,12 @@ void symbol__elf_init(void);
>  int symbol__annotation_init(void);
>  
>  struct symbol *symbol__new(u64 start, u64 len, u8 binding, u8 type, const char *name);
> +struct symbol *symbol__new_bounded(u64 start, u64 len, u8 binding, u8 type,
> +				  const char *name, bool *budget_exceeded);
> +size_t symbol__bytes_used(void);
> +void symbol__account_bytes(size_t bytes);
> +bool symbol__try_account_bytes(size_t bytes);
> +void symbol__unaccount_bytes(size_t bytes);
>  size_t __symbol__fprintf_symname_offs(const struct symbol *sym,
>  				      const struct addr_location *al,
>  				      bool unknown_as_addr,
> diff --git a/tools/perf/util/symbol_conf.h b/tools/perf/util/symbol_conf.h
> index 71f60081a85b..6a16c5badd5e 100644
> --- a/tools/perf/util/symbol_conf.h
> +++ b/tools/perf/util/symbol_conf.h
> @@ -120,6 +120,7 @@ struct symbol_conf {
>  	int		pad_output_len_dso;
>  	int		group_sort_idx;
>  	int		addr_range;
> +	unsigned long	max_symbol_bytes;
>  	DECLARE_BITMAP(parallelism_filter, MAX_NR_CPUS + 1);
>  };
>  
> 
> -- 
> Git-157)
> 
> 

  parent reply	other threads:[~2026-09-21  0:03 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-20  2:33 [PATCH v2 0/4] perf script: Bounded and lazy symbol loading Alireza Haghdoost via B4 Relay
2026-09-20  2:33 ` Alireza Haghdoost
2026-09-20  2:33 ` [PATCH v2 1/4] perf symbols: Fix broken ELF_C_READ_MMAP fallback guard Alireza Haghdoost via B4 Relay
2026-09-20  2:33   ` Alireza Haghdoost
2026-09-20  2:42   ` sashiko-bot
2026-09-20 23:52   ` Namhyung Kim
2026-09-20  2:33 ` [PATCH v2 2/4] perf script: Add --max-symbol-bytes to bound ELF symbol memory Alireza Haghdoost via B4 Relay
2026-09-20  2:33   ` Alireza Haghdoost
2026-09-20  2:43   ` sashiko-bot
2026-09-21  0:03   ` Namhyung Kim [this message]
2026-09-21  4:27     ` Alireza Haghdoost
2026-09-20  2:33 ` [PATCH v2 3/4] perf script: Add --lazy-load-symbols for lazy symbol loading Alireza Haghdoost via B4 Relay
2026-09-20  2:33   ` Alireza Haghdoost
2026-09-20  2:45   ` sashiko-bot
2026-09-20 13:49     ` Alireza Haghdoost
2026-09-21  0:19   ` Namhyung Kim
2026-09-21  4:45     ` Alireza Haghdoost
2026-09-20  2:33 ` [PATCH v2 4/4] perf test: Test lazy symbol loading and symbol memory limits Alireza Haghdoost via B4 Relay
2026-09-20  2:33   ` Alireza Haghdoost
2026-09-20  2:39   ` sashiko-bot

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=arB0RCpi9szb5d_R@z2 \
    --to=namhyung@kernel.org \
    --cc=acme@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=andriin@fb.com \
    --cc=ast@kernel.org \
    --cc=haghdoost@uber.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=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.