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

[Marco Elver <elver@google.com>]

On Tue, Sep 08, 2026 at 02:13PM +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.

Have you measured how much of the memory reduction comes simply from
storing 32-bit compressed frames (patch 9) directly inside the existing
hash-backed struct stack_record? That alone cuts frame storage by
~40-45% across *all* callers (including page_owner and KASAN aux stacks)
with O(1) lookups and none of the trie/bitmap/RCU complexity. If prefix
sharing is still needed on top of that, deduplicating fixed-size (e.g.
4- or 8-frame) immutable segments from caller to callee in the existing
hash table (chained via parent_handle) would avoid mutable child arrays,
RCU retirement, and the bitmap allocator entirely.