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

[Matt Fleming]

On Tue, Oct 20, 2026 at 03:07:40PM +0000, 'Marco Elver' via kernel-team wrote:
> 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.

No, I don't think we've done that. But I will run the numbers and
report back.

Thanks,
Matt