From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ivan Petkov Subject: bug#35139: Rust builds systematically time out Date: Thu, 4 Apr 2019 10:37:03 -0700 Message-ID: <17B412D1-5D9A-40C8-B37E-D8C08F0E9641@gmail.com> References: <878swqtabb.fsf@gnu.org> <87bm1mglus.fsf@gmx.com> <101FBDE5-97FA-4449-9076-DD24C56B8715@gmail.com> <87imvtrc0g.fsf@gnu.org> Mime-Version: 1.0 (1.0) Content-Type: multipart/alternative; boundary=Apple-Mail-4E652100-E4B6-4614-847F-CF56732B7E73 Content-Transfer-Encoding: 7bit Return-path: Received: from eggs.gnu.org ([209.51.188.92]:59355) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hC6JQ-0006Nj-5t for bug-guix@gnu.org; Thu, 04 Apr 2019 13:38:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hC6JO-0005gK-Uw for bug-guix@gnu.org; Thu, 04 Apr 2019 13:38:04 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:59339) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hC6JO-0005gC-QS for bug-guix@gnu.org; Thu, 04 Apr 2019 13:38:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hC6JO-00062r-KO for bug-guix@gnu.org; Thu, 04 Apr 2019 13:38:02 -0400 Sender: "Debbugs-submit" Resent-Message-ID: Received: from eggs.gnu.org ([209.51.188.92]:59073) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hC6IZ-0006M7-Vn for bug-guix@gnu.org; Thu, 04 Apr 2019 13:37:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hC6IY-0004wN-O5 for bug-guix@gnu.org; Thu, 04 Apr 2019 13:37:11 -0400 In-Reply-To: <87imvtrc0g.fsf@gnu.org> List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: Ludovic =?UTF-8?Q?Court=C3=A8s?= Cc: 35139@debbugs.gnu.org --Apple-Mail-4E652100-E4B6-4614-847F-CF56732B7E73 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Danny=E2=80=99s got a patch for turning on parallel tests in #35126 Not sure why the previous tests were running sequentially, but there is a co= mment somewhere saying it=E2=80=99s to avoid EAGAIN errors. --Ivan > On Apr 4, 2019, at 9:06 AM, Ludovic Court=C3=A8s wrote: >=20 > Ivan Petkov skribis: >=20 >>> On Apr 4, 2019, at 1:59 AM, Ludovic Court=C3=A8s wrote: >>>=20 >>> 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 =E2=80=9Cembarrassingly parallel=E2= =80=9D, but >>> we=E2=80=99re running tests with =E2=80=98-j1=E2=80=99.) >>>=20 >>> To summarize, there are two problems: >>>=20 >>> 1. Rust takes too long to build. What can we do about it? Enable >>> parallel builds? >>=20 >> 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. >=20 > Perhaps we could start with: >=20 > "-j" (number->string (min (parallel-job-count) 2)) >=20 > ? >=20 >> Maybe if the bootstrapped versions don=E2=80=99t ever change skipping the= check >> phase will be safe, but I think we should try running parallel tests firs= t >> and see how far that gets us. >=20 > Sounds like a good start. >=20 > So the only reason we=E2=80=99re running tests sequentially is because of m= emory > usage concerns? >=20 > Thanks, > Ludo=E2=80=99. --Apple-Mail-4E652100-E4B6-4614-847F-CF56732B7E73 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Danny=E2=80=99= s got a patch for turning on parallel tests in #35126

Not sure why the prev= ious tests were running sequentially, but there is a comment somewhere sayin= g it=E2=80=99s to avoid EAGAIN errors.

--Ivan

On Apr 4, 2019, at 9:06= AM, Ludovic Court=C3=A8s <ludo@gnu.org> wrote:

= Ivan Petkov <ivanppetkov@gmail.c= om> skribis:

On Apr 4, 2019, at 1:59 AM, Ludovic Court=C3=A8= s <ludo@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
<= blockquote type=3D"cite">
the test suite, whi= ch lasts 2.1h, were =E2=80=9Cembarrassingly parallel=E2=80=9D, but
we=E2=80=99re running tests with =E2=80=98-j1=E2=80=99.)
=

To summarize, there are two problems:
<= /blockquote>

1. Rust takes too long to build.  What can w= e do about it?  Enable
   parallel bui= lds?

Rust tests are designed= to run in parallel, as long as you have enough
RAM, file descriptors, etc. available on the mach= ine for the amount of
concurrency being used. The compiler test suite is largely just compiling
files, so the most imp= ortant resource is probably available RAM/swap.

Perhaps we could start with:

 "-j" (number->string (min (parallel-job-count) 2))
<= span>
?

Maybe if the bootstrapped versions don=E2=80=99t ever change skipping= the check
phase will= be safe, but I think we should try running parallel tests first
<= /blockquote>
and see how far that gets us.

Sounds like a good start.=

So the only reason we=E2=80=99re running tests se= quentially is because of memory
usage concerns?

Thanks,
Ludo=E2=80=99.
=
= --Apple-Mail-4E652100-E4B6-4614-847F-CF56732B7E73--