Re: [PATCH v2] stackdepot: Make max number of pools build-time configurable

[Andrew Morton <akpm@linux-foundation.org>]

On Fri,  4 Jul 2025 13:06:04 +0100 Matt Fleming <matt@readmodwrite.com> wrote:

> From: Matt Fleming <mfleming@cloudflare.com>
> 
> We're hitting the WARN in depot_init_pool() about reaching the stack
> depot limit because we have long stacks that don't dedup very well.
> 
> Introduce a new config to allow users to set the number of maximum stack
> depot pools at build time. Also, turn the silent capping into a
> build-time assert to provide more obvious feedback when users set this
> value too high.
> 
> ...
>
> --- a/lib/Kconfig
> +++ b/lib/Kconfig
> @@ -720,6 +720,12 @@ config STACKDEPOT_MAX_FRAMES
>  	default 64
>  	depends on STACKDEPOT
>  
> +config STACKDEPOT_MAX_POOLS
> +	int "Maximum number of stack depot pools to store stack traces" if EXPERT
> +	range 1024 131071
> +	default 8192
> +	depends on STACKDEPOT

Do we need a range?  If someone wants values outside the range they'll
just edit the Kconfig, shrug.

>  config REF_TRACKER
>  	bool
>  	depends on STACKTRACE_SUPPORT
> diff --git a/lib/stackdepot.c b/lib/stackdepot.c
> index 245d5b416699..1c25c40f31f9 100644
> --- a/lib/stackdepot.c
> +++ b/lib/stackdepot.c
> @@ -36,11 +36,11 @@
>  #include <linux/memblock.h>
>  #include <linux/kasan-enabled.h>
>  
> -#define DEPOT_POOLS_CAP 8192
> +#define DEPOT_MAX_POOLS CONFIG_STACKDEPOT_MAX_POOLS

A boot-time option would be much friendlier.  Can we dynamically
allocate stack_pools[]?

Or possibly even runtime, although perhaps not a good effort-to-utility
ratio.