Re: [PATCH RFC 0/9] Path-compressed trie storage for persistent stack depot records

[Caleb Kan]

On Tue, 18 Aug 2026 at 14:18, Marco Elver <elver@xxxxxxxxxx> wrote:
> Stackdepot's design involves several trade-offs. Changing that needs a
> clearer motivation, in particular, which problem did you run into?
> Which problem were you unable to solve due to stackdepot's current
> design?
>
> The fact we potentially exhaust the pool is known, and the easiest fix
> is to increase the max number of pools. Compressing the records
> introduces a lot of complexity, whereas the simplest fix is to just
> double the pool size. Which environment are you targeting where
> doubling pools wouldn't work?

We ran into this on Cloudflare servers running Generic KASAN.
Stackdepot exhausted its pool budget even after we raised the limit
from 8,192 to 32,768 pools. Increasing it again would buy more time,
but it would not change the linear growth from storing each distinct
trace in full. I'll make the motivation and exhaustion evidence clearer
in v2.

> It sounds nice in theory, but you omitted the most imporant question
> most reviewers would have: what's the performance overhead?

I do not yet have direct measurements of save, lookup, or fetch overhead.
I'll add controlled hash-versus-trie benchmarks, collect data, and include
the results in v2.

> Not great; I'd expect changes to stackdepot internals to retain
> feature parity and no changes in observable behaviour.

For v2, I'll add a best-effort constrained insertion path analogous to
the hash backend, using only immediately available storage and without
allocating, waiting, or blocking.

> I don't see a better option. One issue is that we're increasing stack
> usage where stack_depot_fetch_into() is used, which in some contexts
> is already very constrained.

I'll measure the compiler-reported stack growth for every converted
caller and reduce it where necessary, then report the results with v2.

Thanks,
Caleb