Re: [PATCH RFC v2 00/11] stackdepot: reduce memory use for persistent stack records with a trie

From: Matt Fleming

Date: Wed Oct 07 2026 - 06:45:51 EST


On Tue, Sep 08, 2026 at 02:13:33PM +0100, Caleb Kan wrote:
> Hi,
>
> This series reduces the memory used by persistent stack depot records by
> sharing common frame prefixes in a path-compressed trie.
>
> Cloudflare runs KASAN on pre-production servers so allocation and free
> stack traces are available when diagnosing memory-safety bugs. On some of
> these servers, stack depot exhausted its pool budget even after we raised
> stack_depot_max_pools from 8,192 to 32,768. Once the depot is full, a new
> persistent trace returns no handle and a later KASAN report can lose the
> history needed to explain the bug.
>
> With 4 KiB pages, 32,768 order-2 pools allow 512 MiB of stack storage.
> Doubling the limit again would allow 1 GiB, but it would not change the
> linear growth: the hash backend shares identical complete traces, while
> two traces that differ by one frame are still stored independently.
>
> The trie is opt-in and disabled by default.

Hey Marco,

Do you have any more feedback on this series? Particularly the bug fix
in patch 1?

Thanks,
Matt