Repository navigation
windows: after the #82 per-process cap, the squatter SUM still exceeds the card total and blocks all admission (single-GPU) #103
Description
Follow-up to #82 (per-process VRAM cap, fixed in v0.3.2). The per-process cap works — but it cannot bound the sum, and on a single-GPU desktop the sum keeps berth run admission permanently blocked while a model is loaded.
Environment: v0.3.2 windows-amd64 (official, hash-verified), daemon --gpu 0 --poll 2s, one RTX 5070 Ti (16,303 MiB), Windows 11 26100, built-in PS 5.1.
Engine: llama.cpp (turboquant fork) serving the 27B model with --kv-stream-arena-mib 1220. The arena is a normal 1.22 GB CUDA allocation (the KV cache itself streams from system RAM), so the llama-server figure (~14.2 GB) is real committed weights + arena, not a driver-reporting artifact. The anomalous reading is dwm.exe's, which is unrelated to the engine.
What the fix does correctly (confirmed):
- Each process's "Dedicated Usage" is now capped at the card total.
- LUID adapter pinning is clean on this single-adapter box.
- No regression in daemon, board, or events.
What remains: the admission check sums the (now-capped) per-process squatter values and compares against the card. On this box, with a 27B model loaded, that sum is ~27 GB on a 16.3 GB card even though every individual process is under the cap:
- llama-server (27B): ~14,230 MiB
- dwm.exe (the compositor): ~11,138 MiB (fluctuates 0 → 10,748 MiB between 1-second PDH samples; it is a committed reservation, not real residency)
- 38 squatters total: ~27,973,369,856 B (~27.9 GB)
Consequence — admission is blocked forever while the model runs:
berth run --as probe --needs-mib 100 --wait 12s -- … →
refused: gave up after 12s: next in line: needs 100 MiB; at most 0 MiB can be freed; squatters hold 27233 MiB (exit 75).
The per-process cap bounds one process; the admission path needs a bound on the sum (or a residency-based reading instead of committed reservations). On a single-GPU desktop, berth run is unusable until the card is drained to desktop-only. No multi-GPU needed to reproduce: any single-GPU Windows desktop with a model loaded and the compositor running.
Activity
T-Crypt commentedon Oct 21, 2026
Thanks for the numbers. The per-process table and the 27,973,369,856 B total made this one quick to pin down.
PR #110 fixes it. The broker now caps the squatter total at the memory the driver reports in use, so on your card the sum stops at 15.5 GB instead of 27.9 GB. Admission, the contested-grant figure and the "squatters hold N MiB" wait reason all count the capped total.
berth statusand the events keep each process's raw reading, so you still see dwm.exe at its 11 GB. While the cap applies, the daemon logs one INFO line when that state changes, not one per tick.Your check report on #104 showed two more Windows problems, and I've queued both:
The fix is on main and ships in v0.3.3. On that build, with the 27B loaded, your
berth run --as probe --needs-mib 100probe should get its grant. Reopen this if it doesn't.Merge pull request #110 from T-Crypt/T-Crypt/fix-103
azrael-229 commentedon Oct 21, 2026
Confirmed on this box (build 0.3.3-0.20261021142114, main + #110). llama-server at 14,367 MiB plus dwm's committed reservation (12,307 MiB, PID 1964) — raw PDH sum 27,953 MiB against the 16,303 MiB card. With the cap in place: the daemon logged the one-line clamp (
sum_mib=27960 bound_mib=15688), the wait reason now reads "squatters hold 15,680–15,723 MiB" instead of ~27.9 GB, and a 200 MiB request against ~288 MiB free got its grant (exit 0) — that grant was impossible before the cap, so the needs-mib 100 probe is covered. No need to reopen. The two defects you queued (blank name on the 10.7 GB PID, every composited desktop app in the stowaway list) reproduce on this build; happy to attach a live check report if you file issues for them.T-Crypt commentedon Oct 21, 2026
v0.3.3 is out with this fix: https://github.com/T-Crypt/berth/releases/tag/v0.3.3. With your 27B loaded,
berth run --as probe --needs-mib 100should get its grant now. Reopen this if it still refuses, and paste the wait reason it prints.