Danny’s got a patch for turning on parallel tests in #35126
Not sure why the previous tests were running sequentially, but there is a comment somewhere saying it’s to avoid EAGAIN errors.
--Ivan Ivan Petkov <address@hidden> skribis:On Apr 4, 2019, at 1:59 AM, Ludovic Courtès <address@hidden> wrote:
The build nodes may be slower than the front-end, but still, it seems
unlikely that it would take more than 6h there. (That could happen if
the test suite, which lasts 2.1h, were “embarrassingly parallel”, but
we’re running tests with ‘-j1’.)
To summarize, there are two problems:
1. Rust takes too long to build. What can we do about it? Enable
parallel builds?
Rust tests are designed to run in parallel, as long as you have enough
RAM, file descriptors, etc. available on the machine for the amount of
concurrency being used. The compiler test suite is largely just compiling
files, so the most important resource is probably available RAM/swap.
Perhaps we could start with: "-j" (number->string (min (parallel-job-count) 2))?Maybe if the bootstrapped versions don’t ever change skipping the check
phase will be safe, but I think we should try running parallel tests first
and see how far that gets us.
Sounds like a good start.So the only reason we’re running tests sequentially is because of memoryusage concerns?Thanks,Ludo’.
|