Skip to main content

default_ceiling_mib

Function default_ceiling_mib 

Source
pub fn default_ceiling_mib() -> u64
Expand description

The default per-conversion memory ceiling in MiB, derived from the machine as it is right now.

min(64 GiB, 90 % of AVAILABLE RAM at startup), never above the cgroup-capped total, floored at MIN_DEFAULT_CEILING_MIB. When availability cannot be probed the rule falls back to half of the (cgroup-capped) total, and to FALLBACK_CEILING_MIB when nothing can be probed at all. One sentence for users: a conversion may use most of the RAM that is actually free when it starts, never more than 64 GiB.

History of the rule (each step measured, none guessed):

  • flat 6144 MiB — absurd on a 256 GB host, over-generous on a laptop;
  • 90 % of TOTAL RAM — laptop-hostile: blind to what the session already uses, it let one conversion push a busy 16 GB machine deep into swap;
  • half of TOTAL RAM — laptop-safe but wasteful the other way: on the 31 GB witness laptop it derives ~15.5 GiB while the machine sits idle with ~28 GB free, and the 131 MB witness (24.2 GB core peak) then dies at a fuse it did not need to meet (user directive 2026-08-01: “we can comfortably use up to 24 GB here”);
  • 90 % of AVAILABLE — self-adjusting: on that idle laptop it derives ~25 GiB, and on the same laptop with a browser session holding 6 GB it derives roughly what the half-of-total rule chose. MemAvailable is the kernel’s own estimate of what is reclaimable without swapping, so “the session starts swapping long before the guard fires” — the failure that killed the 90 %-of-total rule — cannot recur by construction.

The 64 GiB cap is not about this machine but about the others: in a parallel fleet the aggregate is N_processes x ceiling, so an uncapped fraction-of-RAM rule on a big host would let a busy fleet OOM it. The cortex_worker fleet overrides this with its own per-child ceiling anyway; the cap keeps the single-process default from being reckless.

Startup-derived, deliberately: the figure is resolved once and becomes the run’s --max-memory, so a neighbours’ later allocations cannot move a running conversion’s fuse mid-flight.