Track AMD's amdgpu GTT-to-memcg accounting (ROCm#6370) and wire it into tally once it lands

[mecattaf]

What happened

AMD confirmed on 2026-09-18 that they will implement cgroup memory (memcg) accounting for
amdgpu GTT allocations on RDNA3.5 APUs (Strix Halo / Ryzen AI Max), which is exactly the
worker's hardware. See ROCm/legacy-rocm-build#6370,
comment by harkgill-amd (AMD/ROCm, author_association: CONTRIBUTOR):

"We've reviewed the ask here of making the driver account GTT usage to the memory cgroup
and will be going forward with it. No timeline on when this'll be out just yet but will
share any updates on this ticket."

No kernel release carries this yet. No timeline was given. Full research memo:
/home/tom/today/review/2026-09-20/ROCM-CGROUP-GPU-MEMORY.md.

Why it matters here

Tonight, on the worker (Linux 7.2.2), GTT is 42.8 GiB in use out of a 124 GiB
amdgpu.gttsize ceiling, and none of it is visible to any cgroup controller: dmem
(present, delegated at root) only accounts the 256 MiB/512 MiB VRAM carve-out, not GTT, and
memory sees nothing GPU-related at all. dmem is also not delegated into user.slice
tonight, so even the VRAM-only accounting that exists would not reach a tally lease's scope.

This directly affects tally#54 (per-lease
MemoryMax via a transient systemd-run scope): until GTT is charged to memcg, a lease's
MemoryMax bounds host RSS only. A ROCm inference lane can hold tens of GB of GPU-resident
memory invisible to its own scope's memory.current, bounded only by the box-wide
amdgpu.gttsize/ttm.pages_limit kernel parameters, which are shared across every lane and
Halogen itself.

Once AMD's fix lands and tally#54 is in place, this becomes a zero-cost win: the same
MemoryMax/memory.peak/OOMPolicy=kill on the lane's scope will cover GPU memory
automatically, no new tally code and no new systemd feature required (this does not need
dmem/DMEMMax, which is a separate, still-unmerged systemd PR, systemd/systemd#37079).

Ask

1. Watch Charge amdgpu GTT allocations to the memory cgroup (memcg) for OOM/Kubernetes accounting on RDNA3.5 APUs ROCm/legacy-rocm-build#6370 for the actual patch/kernel release once AMD posts one,
   and for whether it lands via Dave Airlie's drm/ttm/memcg/lru series or a separate
   amdgpu-specific path.
2. When a kernel carrying the fix is available to NixOS, note it against this issue and
   re-open the "what to do once it lands" checklist in the memo above (section 6c).
3. Independent of the kernel timeline, land tally#54 now for host-RSS containment - it
   becomes strictly more valuable once GPU memory folds into the same accounting, at no
   extra migration cost.
4. Independent of the kernel timeline, consider polling /proc/<pid>/fdinfo
   (drm-resident-gtt, drm-resident-vram) for the Halogen server process as a stopgap for
   per-job GPU memory visibility in the gpu-worker seat meter, ahead of any kernel change.
   This works today on 7.2.2 with no cgroup involvement, though attribution across the
   Halogen container's PID namespace boundary was not established in tonight's read-only
   pass and should be checked before relying on it.

Not in scope for this issue

The gpu-worker/gpu-coordinator seat-feeder gap itself (stale MEASURED placeholder
rows, running: false, hardcoded context_window: 32768) is tracked separately in
dotfiles#432 and tally#63. This issue is specifically about the upstream kernel change and
its downstream effect on tally#54's memory-bound design, not the feeder plumbing.

tier: Opus