The first item from the v1.42 deferred list: a
configurable LRU cap on the per-PID history maps.
On long uptimes with thousands of short-lived procs
(build servers, CI runners), the maps would grow
without bound, eventually consuming significant
memory. v1.43 caps the maps at 500 PIDs by default
and evicts the LRU entry on overflow.
The cap
- App::max_history_pids: usize (default 500)
- 0 = disable (reaper still prunes exited PIDs)
- Shared across the 3 per-PID maps (io_history,
cpu_history, rss_history). They are always
populated in lockstep so a per-PID CPU history
without the corresponding IO history would be
a 'ghost' entry that confuses the renderer.
- disk_history is NOT capped (keyed by disk name,
natural bound on block device count).
LRU tagging
- New App::pid_last_seen: BTreeMap<u32, u64>
- New App::refresh_tick: u64 (incremented on every
update_io_history call)
- We use a refresh counter, not Frame::count(),
because the history update happens during
refresh (not during render). Frame::count would
tag currently-visible PIDs rather than
recently-updated PIDs — a different (and
incorrect) notion.
Eviction algorithm
1. Increment refresh_tick
2. Reap exited PIDs from all 3 maps and
pid_last_seen
3. If pid_last_seen.len() > cap: sort by tick
ascending, take the first overflow entries,
remove from all 3 maps + pid_last_seen
4. Continue with the existing pipeline
Cost: O(n log n) per refresh, n bounded by 500.
At 500 PIDs: ~4500 comparisons per refresh,
<100µs. Memory budget: ~28 KB at cap, vs
unbounded growth without the cap (~5.5 MB at
100k PIDs).
Tests
- 3 new tests (eviction removes oldest, cap=0
disables, no-op under cap).
- 186/186 tests pass (was 183 in v1.42).
The improvement plan doc is also updated with §67
covering the v1.43 architecture, the cap policy,
the LRU tagging, the eviction algorithm, the
memory budget, and the v1.44 deferred list.
vasilito
f83a059c25