Per-root resident artifacts are capped per-item but have no aggregate bound across roots

[iceteaSA]

Every resident artifact has a sensible individual cap. Nothing caps their sum.

search_index    SPIMI_SOFT_LIMIT_BYTES 128MB / HARD 256MB, MAX_ENTRIES 10M   per root
semantic_index  max_files                                                    per root
callgraph store SQLite + buffers                                             per root
symbol cache    disk-backed                                                  per root
borrowed cache  BORROWED_INDEX_CACHE_CAPACITY = 4                            process-wide ✓

Only the borrowed-index cache is bounded process-wide. The rest are per-root, and the process holds as many sets as it has bound roots. IDLE_ROOT_TTL (30 min) is the only thing that ever reclaims them, and it's a liveness rule, not a budget — a daemon with N actively-used roots keeps N full artifact sets resident by design, and no configuration expresses "this process should not exceed X".

Live instance right now, ~2 h uptime:

VmRSS   2.95 GB
VmData 10.97 GB
Threads   123
31 distinct sessions in the last 110 perf ticks

This is the same shape as #202, one layer up. There, InspectManager lived in the per-root AppContext, so N roots meant N rayon pools (88 inspect threads of 211). The fix made the pool process-wide. The artifacts have the identical structure — bounded per item, multiplied per root, unbounded in aggregate — and no equivalent fix.

Two reasons I think it's worth a bound rather than just an eviction TTL:

It's the allocation pattern that strands free space. Many large, long-lived, differently-sized buffers arriving and departing on independent schedules (bind, watcher churn, idle eviction, reconfigure) is the textbook way to interleave free chunks beneath live ones. That's the mechanism behind the fragmentation in #205 — where measurement showed 15 of 16 arenas at ≥0.86 free with one arena doing the work — and malloc_trim structurally can't reclaim it.

A multi-root daemon has no backpressure. Idle eviction is time-based, so 31 sessions across many roots in one process means the peak is set by how many roots happen to be warm at once, not by anything the operator can configure. On this host that contributed to an OOM kill of the daemon (Consumed … 29.5G memory peak, 38.6G memory swap peak at 41 h uptime).

What I'm not proposing: a specific mechanism. LRU eviction on a byte budget, a total-artifact-bytes config with eviction of the coldest root, or per-root caps scaled by root count are all plausible and have different failure modes — evicting a root someone is about to use costs a rebuild, which may be worse than the memory it saves. You'd know which fits the eviction machinery that already exists.

The concrete ask is whether an aggregate bound belongs here at all, or whether the intended answer is "run fewer roots per daemon". If it's the latter that's worth stating somewhere, because the daemon transport makes many-roots-per-process the default rather than the exception.

Related: #205 (fragmentation measurement), #202 (same shape, per-root thread pools).

[ualtinok]

Accepted — the structural read is right, and the #202 parallel is the correct lens: bounded per item, multiplied per root, unbounded in aggregate, with the additional bite you named that the allocation pattern itself is the fragmentation mechanism from #205. The borrowed-index cache being the only process-wide bound is an accurate census of the current state.

This one is getting a design cycle rather than a quick bound, deliberately. An aggregate budget forces real policy questions that a cap constant would silently answer badly: evicting a hot root's search index trades RAM for rebuild churn (and on this codebase a cold rebuild is exactly the storm class we spent last week killing); LRU across artifact types is wrong (a 200 MB search index and a 200 MB callgraph store have very different rebuild costs and hit rates); and the budget interacts with the idle-root TTL and the cold-build limiter, which are liveness rules, not budgets — composing a third regime on top without a design pass is how we'd get eviction storms. The shape I expect the design to land on is a process-wide accounting layer (the per-root attribution from the memory snapshots already exists) driving priority-aware eviction through the existing idle-eviction machinery, with the budget expressed as a soft target rather than a hard cap. It'll get an adversarial review before implementation, same as the other concurrency-adjacent designs here.

Your VmData 10.97 GB vs RSS 2.95 GB gap is also worth keeping in frame — a large slice of that aggregate is already MADV_FREE'd or never-touched; the budget design has to measure what's actually resident per artifact, not summed capacity, or it will evict against phantom pressure. The per-arena distribution work you're doing on #205 feeds this directly.

[iceteaSA]

The residency point is right, and it's worth more than a caveat — I measured it, and the error a capacity-summing budget would make is large enough to invert decisions.

Same daemon, now 8 h uptime:

VmData  12.71 GB
VmRSS    2.23 GB
VmSwap   2.18 GB
committed (RSS+swap) = 4.42 GB = 34% of VmData

Per-region, from smaps — 157 large anonymous rw mappings ≥32 MB:

commit fraction	regions	virtual
0–5%	70	5.68 GB
5–25%	22	1.48 GB
25–75%	19	1.99 GB
75–100%	46	3.22 GB

A budget summing capacity charges 12.37 GB. A budget summing residency charges 4.34 GB. 2.9× overcharge.

The distribution is what makes this a correctness issue rather than a scaling constant. It's bimodal: 70 regions are effectively untouched while 46 are nearly fully committed. A capacity-based budget doesn't overcharge uniformly — it overcharges those 70 regions by ~20× and the other 46 barely at all. So under pressure it would preferentially evict whatever happens to hold large sparse mappings, which is the opposite of what you want, and it would fire while 8 GB of the "usage" it's reacting to isn't costing the box anything.

Worth noting the one thing I could not find: zero regions are fully untouched. Every one has at least some resident pages, so an eviction policy can't cheaply identify "reserved but unused" artifacts by a null test — it needs the actual fraction. Cheap to read (Rss + Swap per mapping in smaps) but it does mean attribution has to be per-mapping and periodic rather than a one-time classification.

One caution on wiring my #205 work into this, since you named it as an input. The per-arena distribution answers "is free space reclaimable" — 15 of 16 arenas at ≥0.86 free, one arena doing the work. It does not attribute bytes to artifacts. glibc arenas are per-contending-thread, not per-subsystem: a single arena holds allocations from whatever threads landed on it, so arena-level data can't tell you the search index owns X and the callgraph store owns Y. For a priority-aware policy that needs per-artifact residency, arena data is the wrong granularity and the per-root memory snapshots you mentioned are the right one. The two are complementary — mine says how much of the total is recoverable in principle, yours says who to charge — but substituting one for the other would put phantom precision into the accounting layer.

Design cycle over quick bound is clearly right, and the rebuild-cost asymmetry argument is the part I'd have got wrong: I was thinking in bytes, and a 200 MB search index and a 200 MB callgraph store having different rebuild costs makes byte-uniform LRU actively harmful. Happy to run measurements against a proposed policy if that's useful during the design pass — I have the harness and the census tooling from #205 already.