c97bee80

By: Tom Sydney Kerckhove <syd@cs-syd.eu>

Respect the cores nix gave the build

A test suite compiled with -N asks the RTS for every core of the machine
it runs on, which inside a nix build is not what the build was given.
Nix's cores setting reaches a build only as NIX_BUILD_CORES, so read
that, and let it decide how parallel to run when nothing else does.
Nix's --max-jobs is not visible to a build at all, so there is nothing
to respect there.

It narrows, and only narrows. Anything configured explicitly still
decides: --jobs, --synchronous, SYDTEST_JOBS, threads in the config
file, and --debug all win, so an ambient variable cannot override a
config file. More cores than the RTS has capabilities leaves the count
alone rather than raising it, because running more tests at once than
the RTS can overlap is contention with no parallelism to show for it: a
suite not compiled with -N has one capability, and running it 64 ways
because the builder has 64 cores would be a change for the worse. The
narrowing also happens after the warning about compiling with -N is
decided, so a suite stuck on one capability is still told to add it.

Zero threads now means every capability rather than an asynchronous
runner with no workers. --jobs 0 left nothing to take tests off the
queue and the suite died with "thread blocked indefinitely in an STM
transaction". Nix documents 0 as "use every core", which is how
NIX_BUILD_CORES=0 reaches a build wherever stdenv has not already
replaced it with a core count, and the mutation driver's own job counts
have always treated it that way, so every route into a thread count now
agrees.

Total

3m47s

Created 1 day ago Started 1 day ago Finished 1 day ago

Timeline