chadtmiller.com/knotless

Switch repository

Loading…

What changes

harness/cov.mjs builds the instrumented tests with as many crates at once as the CPUs its cgroup gives it, and one for each 2.5 GiB of its memory limit at most. On runner.knotless.dev, whose runs get 4 CPUs and 7 GiB, that is 2. Where the cgroup sets no limit, as for the main host's runs or a laptop, nothing changes. A CARGO_BUILD_JOBS already set is kept. The runner host's README now says 7 GiB, as the host runs, and why cov caps the build.

Why

cargo reads the host's cores, not the container's CPU quota: nproc in a 4-CPU run on the 8-core runner host says 8. So the test workflow built 8 crates at once in 7 GiB. Under coverage, knotless-serve's rustc alone takes near 2.7 GB. On 2026-11-02 the kernel killed it three times (dmesg: rustc invoked oom-killer, memcg-constrained), each failing a pull's test pre-flight. A failure on main's current tip ejects the pull, and the queue won't run it again until main moves. One build running as this was written peaked at 7,168 MiB, the whole limit.

More memory per run would leave no room for two runs on a 16 GB host, and two at once is what keeps pulls' checks moving there. Fewer crates at once costs little, as the slow part is serial anyway: knotless, then knotless-serve, then its test binaries.

How it was checked

I checked the arithmetic against the runner's own cpu.max and memory.max (400000 100000, 7516192768): 2. A 2-CPU, 3 GiB run gets 1, and no limit gives none. This pull's own test runs on the runner host with the cap, and its log says cov: building 2 crates at once. Because cov.mjs changed, every binary runs fresh, so it is a full build to time against earlier runs.

Shortcomings

A cold full build takes longer at 2 crates than at 8. Most pulls start warm, and rebuild only what they change. The 2.5 GiB per crate is set from knotless-serve's peak. A heavier crate later would need it raised.

🤖 Generated with Claude Code

This sets CARGO_BUILD_JOBS in harness/cov.mjs to the smaller of the cgroup's CPU quota and its memory divided by 2.5 GiB, with a floor of 1. It leaves the variable alone if it is already set or if the cgroup has no limit. The runner README now says 7 GiB and explains the cap.

I found nothing that must change.

• readFileSync and join are already imported.
• The unreadable-file and max cases fall back to no cap.
• Your numbers (400000 100000 and 7 GiB) give floor(4) and floor(2.8), so 2.
• The cgroup v1 layout isn't handled. It just means no cap, which is the old behaviour.

I did not read the checks, so I can't confirm the pull's own test run logged cov: building 2 crates at once. The pull_diff tool returned a 500, so I read the change through diff.