Module cap 

How much memory this process actually gets, and what to do with that number.

A server that sizes itself from the machine is wrong on every machine where it is not the only thing running, and in 2026 that is most of them. Inside a container the kernel will happily tell you the host has 512 GB while the cgroup this process lives in will kill it at 2. So the question is not what the machine has, it is what this process is allowed to use, and the answer is the smaller of the two.

The over 4 rule

Cap::budget is a quarter of the limit, not the whole of it, and that quarter is not a hedge. 16-implementation-plan.md M5 records what happened in aki when the pools were sized straight from memory.max: the same bytes were charged twice, once to the pool and once to the pages the pool was sitting on, and a result that should have been 1.58x came out at 5.14x and 5.77x. Dividing by four fixed it. That is an empirical number rather than a derived one, which is exactly why both the limit and the budget are reported rather than only the one that gets used. The next person to be surprised by this should be able to see both numbers without reading the source.

Where the numbers come from

Under cgroup v2 the limit is in memory.max, in the directory named by the 0:: line of /proc/self/cgroup under the cgroup mount. A limit can be set on any ancestor and the tightest one wins, so this walks up to the mount point taking the smallest number it finds. Under cgroup v1 the same idea lives in memory/memory.limit_in_bytes, where “no limit” is a very large number rather than a word. Neither file exists anywhere but Linux, and on a machine without them there is no limit to find, which is the honest answer and not an error.

The parsing and the walk are separate from the paths they normally read, so the tests build a directory tree and check the walk against it on every platform rather than only on the one where it matters.

Structs

Cap

What this process is allowed to use.

Functions

cap

The reading, taken once and kept.