Resolve the runtime plan and apply it, first thing at boot. It never aborts the boot, and the plan it returns is the effective one, so downstream sizing computes from what the RTS runs with.

The RTS posture the process is actually running with, read at boot by currentRtsPosture.

What the cgroup (v2) grants this process: the CPU quota in cores and the memory ceiling in bytes. Nothing per axis when the file is absent or carries the unlimited max sentinel.

The runtime configuration the resolution reads. Each unset field falls to the next rung, and roCoresCeiling bounds the last rung alone.

Where a resolved value came from, for the boot log's provenance clause.

The resolved runtime posture: the capability count, allocation area and heap ceiling to run with, each with its provenance. A FromRts entry means leave the live posture alone.

The provenance as a bare clause, for consumers composing their own log lines.

Resolve the runtime plan: capabilities down the four-rung ladder, the heap ceiling from maxHeapBytes, else the cgroup limit, else GHCRTS, and the allocation area to fit either bound.

The heap ceiling derived from a cgroup memory limit, floored at half the limit. The nursery counts inside -M (GHC 9.6 and later), so only an overshoot allowance and off-heap memory come off.

The per-capability allocation area for a memory limit: an eighth of the limit across the capabilities, in whole MiB from 4 to 64. A smaller nursery costs collector time, not a core.

The RTS flags the plan requires beyond the live posture, in GHCRTS syntax. A FromRts entry never contributes a flag, because it is the live posture.

One axis of the runtime posture after the boot applied the plan. An apply can fail, so downstream sizings read effectiveCapabilities and effectiveHeapCeiling, never the desired plan.

The runtime plan reconciled with the posture the RTS actually runs: each planned axis as a desired/observed pair, plus the observed-only datapoints downstream sizing needs.

Whether the live RTS backs an axis (desired and observed agree).

Pair the desired plan with the posture the RTS reports, axis by axis.

The effective plan a successful application would produce, observed equal to desired. check-config sizes from this because it applies nothing, so its own posture is not the boot's.

The live capability count: budgets must never exceed what the RTS actually runs with, so the observed side is authoritative. An unenforced count degrades the provenance to FromRts.

The sizing ceiling: the tighter of desired and observed. An observed -M below the plan binds, and an absent one leaves the desired ceiling standing on the cgroup limit's OOM backstop.

The boot log's posture lines, one decision per line with its provenance. The allocation area has no config key: the cgroup limit or an operator GHCRTS sets it.

The boot log's posture warnings: an axis the RTS is not enforcing, and a capability count no entitlement backs.

Parse a cgroup-v2 cpu.max body. "quota period" yields the granted cores, and the max sentinel or a malformed body yields Nothing: no limit is inferred from noise.

Parse a cgroup-v2 memory.max body: a byte count, or the unlimited max sentinel (Nothing). A malformed body yields Nothing.

Read a file that may be absent, as off a cgroup-v2 host. Every other IO error propagates.

The inactive_file bytes in a cgroup-v2 memory.stat body: page cache the kernel reclaims first.

Memory in use less reclaimable page cache, in thousandths of the limit, from a cgroup's readings.

A reader for this process's cgroup memory use less reclaimable file pages, in thousandths of the tightest memory.max above it. It reads Nothing when no limit binds or a read fails.