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 > On Apr 4, 2019, at 9:06 AM, Ludovic Courtès <l...@gnu.org> wrote: > > Ivan Petkov <ivanppet...@gmail.com> skribis: > >>> On Apr 4, 2019, at 1:59 AM, Ludovic Courtès <l...@gnu.org> 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 memory > usage concerns? > > Thanks, > Ludo’.
