Container teardown latency here is unpredictable, not merely slow. Measured
2026-09-13 on the same container in the same session: once ~55s, once 0s.
Removing a container holding ~92 GB of GPU memory plus the offloaded PLE
mapping leaves an Exited record owning its name for that whole window, so any
fixed wait or retry budget is a guess that will eventually be wrong -- a 12x5s
retry lost arm k1 by roughly two attempts.
Arms now use $NAME_BASE-$arm, set in boot() after stop_bench has torn down the
previous arm. Names are never reused, so the collision is impossible by
construction and teardown latency stops being load-bearing. cleanup() reaps
every fn-mtp-bench-* container at exit.
stop_bench keeps the GPU-memory wait -- the next container genuinely needs the
device, and unlike the container record nvidia-smi clears promptly and reports
truthfully. It no longer waits on the container listing at all.
Three earlier hypotheses were wrong and are recorded so they are not retried:
the name is not held by a phantom (the container is present and Exited), the
removal does not fail (rm -f succeeds; it is asynchronous), and GPU memory
release does not track name release (memory frees first, by a wide margin).
vh
f9a8f176ca