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

[Marco Elver]

On Fri, 6 Nov 2026 at 14:18, Matt Fleming <mfleming@xxxxxxxxxxxxxx> wrote:
>
> (Sorry for the delay)
>
> 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.
>
> Yeah 40-45% is the right ballpark. In our measurements, using 32-bit
> frames gets us around 41.8% reduction in stack depot pool usage.
>
> > 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.
>
> That's an interesting idea. I'll take a look at that so we can compare
> numbers.
>
> In the meantime, should I send a series that just does the 32-bit
> compressed frames?

Yes, if you see it provides real benefits on its own. It's also a lot
simpler, and having that as an independent series might be a lot less
contentious.