| Message ID | 20190403170044.21420-1-dannym@scratchpost.org |
|---|---|
| State | Accepted |
| Headers | show |
| Series | [bug#35126] gnu: rust: Enable parallel tests starting with 1.26. | expand |
| Context | Check | Description |
|---|---|---|
| cbaines/applying patch | fail | Apply failed |
Functionally, it looks good to me (and should speed up all subsequent builds)! Just curious, any reason why we’re doing this starting 1.26 and not earlier? —Ivan
Hi Ivan, On Wed, 3 Apr 2019 17:52:35 -0700 Ivan Petkov <ivanppetkov@gmail.com> wrote: > Functionally, it looks good to me (and should speed up all subsequent builds)! > > Just curious, any reason why we’re doing this starting 1.26 and not earlier? There have been problems with it in very old Rust builds which is why it was disabled in the first place. Icecat uses Rust 1.24 - I selfishly don't want to change that one because I use it ;) And I'm not sure when (in which version) they fixed the parallel tests (if they fixed them, that is). So I'm kinda starting in the middle... (I'm now up to and excluding rust 1.30.1 with enabled parallel tests with -j4) (rust 1.30.1 is still building for a few rounds)
Hi Danny, > On Apr 4, 2019, at 11:29 AM, Danny Milosavljevic <dannym@scratchpost.org> wrote: > > There have been problems with it in very old Rust builds which is why it was > disabled in the first place. > > Icecat uses Rust 1.24 - I selfishly don't want to change that one because I > use it ;) Can’t say that I fault you there, I really hate having to rebootstrap the entire rust chain ;) > And I'm not sure when (in which version) they fixed the parallel tests (if > they fixed them, that is). > > So I'm kinda starting in the middle... We can always try moving it up to earlier versions as necessary, so I’m fine with landing this as long as all the later tests build fine! —Ivan
All tests of all Rust >= 1.26 just successfully completed--with parallel tests. Should we limit the number of parallel jobs? I think at least armhf is going to be very overloaded otherwise. To which value?
Hi Danny, > On Apr 5, 2019, at 7:11 AM, Danny Milosavljevic <dannym@scratchpost.org> wrote: > > Should we limit the number of parallel jobs? I think at least armhf is going > to be very overloaded otherwise. To which value? Do the armhf builders define that they have fewer cores available? If not, we could cap the max jobs to 2, although it would be nice to potentially use as many cores as are available for non-armhf builds. —Ivan
On Fri, 5 Apr 2019 08:36:44 -0700 Ivan Petkov <ivanppetkov@gmail.com> wrote: > Hi Danny, > > > On Apr 5, 2019, at 7:11 AM, Danny Milosavljevic <dannym@scratchpost.org> wrote: > > > > Should we limit the number of parallel jobs? I think at least armhf is going > > to be very overloaded otherwise. To which value? > > Do the armhf builders define that they have fewer cores available? > > If not, we could cap the max jobs to 2, although it would be nice to potentially > use as many cores as are available for non-armhf builds. I think the problem is RAM usage. Arm machines have little RAM and will choke if too many memory-expensive things run in parallel.
> On Apr 6, 2019, at 3:48 AM, Danny Milosavljevic <dannym@scratchpost.org> wrote: > > On Fri, 5 Apr 2019 08:36:44 -0700 > Ivan Petkov <ivanppetkov@gmail.com> wrote: > >> Hi Danny, >> >>> On Apr 5, 2019, at 7:11 AM, Danny Milosavljevic <dannym@scratchpost.org> wrote: >>> >>> Should we limit the number of parallel jobs? I think at least armhf is going >>> to be very overloaded otherwise. To which value? >> >> Do the armhf builders define that they have fewer cores available? >> >> If not, we could cap the max jobs to 2, although it would be nice to potentially >> use as many cores as are available for non-armhf builds. > > I think the problem is RAM usage. Arm machines have little RAM and will choke > if too many memory-expensive things run in parallel. I’d anticipate that building rustc itself would be the most memory intense operation, I think most of the individual tests aren’t anywhere nearly as big… —Ivan
Hi Danny, When it’s time to merge this in, would you mind also changing the `generate-checksums` procedure in (guix build cargo-utils) to omit the `src-name` parameter (as mentioned in #35155)? If we’re going to be having the CI bootstrap almost the whole rustc chain for this change, we might as well combine them together and build all at once! Thanks, —Ivan
diff --git a/gnu/packages/rust.scm b/gnu/packages/rust.scm index 63426a12fc..23b28cce23 100644 --- a/gnu/packages/rust.scm +++ b/gnu/packages/rust.scm @@ -724,6 +724,11 @@ jemalloc = \"" jemalloc "/lib/libjemalloc_pic.a" "\" `(modify-phases ,phases ;; binaryen was replaced with LLD project from LLVM (delete 'dont-build-native) + (replace 'check + (lambda* _ + ;; Enable parallel execution. + (invoke "./x.py" (string-append "-j" (number->string (parallel-job-count))) "test" "-vv") + (invoke "./x.py" (string-append "-j" (number->string (parallel-job-count))) "test" "src/tools/cargo"))) (replace 'remove-unsupported-tests (lambda* _ ;; Our ld-wrapper cannot process non-UTF8 bytes in LIBRARY_PATH.