Capping an app-level cache barely lowers the memory of a vendor-library waveform reader; measure the instantaneous tree PSS

A same-memory benchmark tried to match two waveform readers' memory by capping the app's own block cache (300 MB) on the heavier reader. The instantaneous total PSS of its process tree fell only 0-10% (≈1.9 → 1.7 GB). Most of the memory sat in the vendor reader library and its per-worker copies, not in the cache. The cap also made repeat point reads slower (1 ms → ~20 ms). Going the other way, giving the lighter reader +190 MB of tile/store cache made whole-range reads slower (0.98 → 1.35 s), so its default was already its best configuration.

Method notes: - Sample /proc/<pid>/smaps_rollup PSS for every process in the tree at the same moment and report the peak of the sum. A sum of per-process peaks is only an upper bound. - Run each lane cold then warm back to back. A drop_caches before another lane's cold run silently turns the next 'warm' run cold. - Check page-cache residency with fincore (util-linux-extra on Ubuntu 24.04) before every run: 0 B means cold, file size means warm. - Check /proc/<pid>/maps for two different zstd copies loaded in one process. It works when the library doesn't print its version.