mirror of
https://github.com/stablyai/orca.git
synced 2026-09-22 08:02:28 +00:00
m4air
e5ef884048
`memory.max` and `memory.high` are enforced as the MINIMUM over our cgroup and its ancestors, but only our own level was read. A `snap set-quota --memory` slice, a `MemoryMax=` on `user.slice` and a Kubernetes pod cgroup all sit above the unit we run in, so our own file reads `max` under every one of them: the report showed no ceiling, the label stayed `mem-available`, and the doc told the reader that a missing ceiling means unlimited — clearing check 2 on exactly the sandboxes this module names as its reason to exist. Walk the chain to the mount root and take the lowest for each file. Where the binding ceiling is an ancestor's it is shared with our siblings, so our own `memory.current` is not comparable to it; `systemMemoryCgroupCeilingCurrentMB` carries the usage that ceiling actually counts against, and appears only in that case. `oom_kill` needed nothing: the kernel credits it to the victim's cgroup and every cgroup above, whichever level's limit fired. The `max`/`high` event counters stay at our level and the doc now says a zero there clears nothing. Also closes four mutations that no test could falsify: the 30% stall threshold (only a self-referential boundary case pinned it, so 5% or 29% stayed green), `someAvg60` in both stall scopes (deletable and mislabelable), the pseudo-file read's error swallow (the test double answers what the swallow produces, so it could never exercise it), and PSI's non-numeric field guard.