[PATCH] Allow parallel downloads and builds

  • Open
  • quality assurance status badge
Details
5 participants
  • Julien Lepiller
  • Ludovic Courtès
  • Pierre Neidhardt
  • Maxim Cournoyer
  • zimoun
Owner
unassigned
Submitted by
Julien Lepiller
Severity
normal
J
J
Julien Lepiller wrote on 21 Feb 2020 23:53
(address . guix-patches@gnu.org)
20200221235307.535fb453@tachikoma.lepiller.eu
Hi guix!

This patch allows to count builds and downloads separately. The idea is
that downloads need bandwidth, but no CPU, while builds do not need
bandwidth, but need CPU. With this patch, guix will be able to download
substitutes while building unrelated packages. Currently, guix needs to
wait for the download to finish before proceeding to the build. This
should reduce the time of guix commands that need to build and download
things at the same time.

What do you think?
L
L
Ludovic Courtès wrote on 24 Feb 2020 22:23
(name . Julien Lepiller)(address . julien@lepiller.eu)(address . 39728@debbugs.gnu.org)
87h7zfel26.fsf@gnu.org
Hi!

Julien Lepiller <julien@lepiller.eu> skribis:

Toggle quote (10 lines)
> This patch allows to count builds and downloads separately. The idea is
> that downloads need bandwidth, but no CPU, while builds do not need
> bandwidth, but need CPU. With this patch, guix will be able to download
> substitutes while building unrelated packages. Currently, guix needs to
> wait for the download to finish before proceeding to the build. This
> should reduce the time of guix commands that need to build and download
> things at the same time.
>
> What do you think?

I think it’s a good idea!

I wonder what the UI will look like: (guix status) would no longer
display a progress bar when there’s more than on job (build or download)
taking place at the same time.

Toggle quote (4 lines)
>>From 9c059d81ba4f4016f8c400b403f8c5edbdb160c2 Mon Sep 17 00:00:00 2001
> From: Julien Lepiller <julien@lepiller.eu>
> Date: Fri, 21 Feb 2020 23:41:33 +0100
> Subject: [PATCH] nix: Count build and download jobs separately.
^
I’d write “daemon:” here. :-)

Toggle quote (1 lines)
> This allows to run downloads (that take bandwith) and builds (that take
^
“This allows us”

Toggle quote (7 lines)
> CPU time) independently from one another.
>
> * nix/nix-daemon/guix-daemon.cc: Add a max-download-jobs option.
> * nix/libstore/globals.hh: Add a maxDownloadJobs setting.
> * nix/libstore/globals.cc: Add a default value to it.
> * nix/libstore/build.cc: Manage build and download jobs separately.

For the final patch, please specify the entities changed (classes,
functions, etc.).

Toggle quote (4 lines)
> + /* Number of download slots occupied. This includes substitution and
> + built-ins. */
> + unsigned int nrDownloads;

Note that not all builtins are downloads. Fixed-output derivations are
(usually) also downloads.

(It’d be the first time the daemon gets a notion of “download”. We
should make sure it doesn’t conflict with other assumptions.)

Toggle quote (7 lines)
> /* Registers a running child process. `inBuildSlot' means that
> the process counts towards the jobs limit. */
> void childStarted(GoalPtr goal, pid_t pid,
> - const set<int> & fds, bool inBuildSlot, bool respectTimeouts);
> + const set<int> & fds, bool inBuildSlot, bool inDownloadSlot,
> + bool respectTimeouts);

How about replacing these two Booleans by a single enum?

Toggle quote (4 lines)
> + unsigned int curDownloads = worker.getNrDownloads();
> + if (curDownloads >= (settings.maxDownloadJobs==0?1:settings.maxDownloadJobs) &&
> + fixedOutput) {

This is hard to parse and lacking spacing. :-) Perhaps make an
intermediate function or variable?

Toggle quote (5 lines)
> +void Worker::waitForDownloadSlot(GoalPtr goal)
> +{
> + debug("wait for download slot");
> + if (getNrDownloads() < (settings.maxDownloadJobs==0?1:settings.maxDownloadJobs))

Same here.

Toggle quote (6 lines)
> @@ -118,6 +119,7 @@ void Settings::update()
> {
> _get(tryFallback, "build-fallback");
> _get(maxBuildJobs, "build-max-jobs");
> + _get(maxDownloadJobs, "download-max-jobs");

We should also allow ‘set-build-options’ to set this option, as well as
add it to ‘%standard-build-options’. That can prolly come in a separate
patch.

Toggle quote (3 lines)
> + { "max-downloads", 'D', n_("N"), 0,
> + n_("allow at most N download jobs") },

We’d need to update doc/guix.texi.

It would be great if you could test this patch for your daily usage. I
find it surprisingly easy to break things in the daemon. :-)

Thank you!

Ludo’.
Z
Z
zimoun wrote on 25 Feb 2020 16:21
(name . Ludovic Courtès)(address . ludo@gnu.org)
CAJ3okZ1YaReDRboqpRvO4QJJia_+HViApDK6Mf8HwHRMHoEk-Q@mail.gmail.com
Hi Julien,

On Mon, 24 Feb 2020 at 22:43, Ludovic Courtès <ludo@gnu.org> wrote:
Toggle quote (18 lines)
> Julien Lepiller <julien@lepiller.eu> skribis:

> > This patch allows to count builds and downloads separately. The idea is
> > that downloads need bandwidth, but no CPU, while builds do not need
> > bandwidth, but need CPU. With this patch, guix will be able to download
> > substitutes while building unrelated packages. Currently, guix needs to
> > wait for the download to finish before proceeding to the build. This
> > should reduce the time of guix commands that need to build and download
> > things at the same time.
> >
> > What do you think?
>
> I think it’s a good idea!
>
> I wonder what the UI will look like: (guix status) would no longer
> display a progress bar when there’s more than on job (build or download)
> taking place at the same time.

Speaking about progress bar, it could be nice (as an improvement) to
have a concurrent progress bar. As an example, see:



Toggle quote (3 lines)
> It would be great if you could test this patch for your daily usage. I
> find it surprisingly easy to break things in the daemon. :-)

How can I do that?
After the 'make', how can change the daemon? And then revert it again
to the default one?


Cheers,
simon
J
J
Julien Lepiller wrote on 25 Feb 2020 16:39
(address . 39728@debbugs.gnu.org)
62A3FE42-52DD-4E51-9AD1-242B86B6A391@lepiller.eu
Le 25 février 2020 10:21:24 GMT-05:00, zimoun <zimon.toutoune@gmail.com> a écrit :
Toggle quote (45 lines)
>Hi Julien,
>
>On Mon, 24 Feb 2020 at 22:43, Ludovic Courtès <ludo@gnu.org> wrote:
>> Julien Lepiller <julien@lepiller.eu> skribis:
>
>> > This patch allows to count builds and downloads separately. The
>idea is
>> > that downloads need bandwidth, but no CPU, while builds do not need
>> > bandwidth, but need CPU. With this patch, guix will be able to
>download
>> > substitutes while building unrelated packages. Currently, guix
>needs to
>> > wait for the download to finish before proceeding to the build.
>This
>> > should reduce the time of guix commands that need to build and
>download
>> > things at the same time.
>> >
>> > What do you think?
>>
>> I think it’s a good idea!
>>
>> I wonder what the UI will look like: (guix status) would no longer
>> display a progress bar when there’s more than on job (build or
>download)
>> taking place at the same time.
>
>Speaking about progress bar, it could be nice (as an improvement) to
>have a concurrent progress bar. As an example, see:
>
>http://hackage.haskell.org/package/concurrent-output
>
>
>> It would be great if you could test this patch for your daily usage.
>I
>> find it surprisingly easy to break things in the daemon. :-)
>
>How can I do that?
>After the 'make', how can change the daemon? And then revert it again
>to the default one?
>
>
>Cheers,
>simon

On the guix system, try (in a guix environment guix) sudo herd stop guix-daemon; sudo ./pre-inst-env guix-daemon --build-users-group=guixbuild

To revert back, kill this (^C) and sudo herd start guix-daemon.
P
P
Pierre Neidhardt wrote on 26 Feb 2020 11:36
(name . Julien Lepiller)(address . julien@lepiller.eu)
87zhd58wjz.fsf@ambrevar.xyz
Thank you so much for this, Julien!

There was a thread on this topic on the mailing list:
(could not find the first email :p).

There were a couple other issues that were mentioned there.
This patch would be a first step towards more parallelization!

--
Pierre Neidhardt
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEUPM+LlsMPZAEJKvom9z0l6S7zH8FAl5WSjAACgkQm9z0l6S7
zH8IqwgArM56uM65zPsqx/L/OPSJGWRxh9a2nvKlnjwfn5OrksFiiDZYBZ+EDUxd
lgZHHr2oChbBgmKxEP3pDQN9d62Ikze5G9oFgQulXkmOEfjvePDUEbcVWcjxTclG
z8m1cbef2AoIzc8ITVyp9yND1HWTgFGSximmN2Y2NJGTDfOy+1WSSXdNil8kZQWC
1TgiJNzFg6nIfjeX2p+wVM64w6x1NeT64p+blNUpDj8/ReHY69sbr156PC1rzTB6
X3dkdGIIQX2vQJ5wsl90MVT7AMlW1bMPc2nUn37qhzb8fvpwiExt5NMcAMGdYN1K
C2lg+3jlzs62QkOfmUUVuGplfDilFA==
=fs5l
-----END PGP SIGNATURE-----

M
M
Maxim Cournoyer wrote on 14 Jul 2021 04:49
Re: bug#39728: [PATCH] Allow parallel downloads and builds
(name . Julien Lepiller)(address . julien@lepiller.eu)(address . 39728@debbugs.gnu.org)
874kcxr4o1.fsf@gmail.com
Hello!

Julien Lepiller <julien@lepiller.eu> writes:

Toggle quote (12 lines)
> Hi guix!
>
> This patch allows to count builds and downloads separately. The idea is
> that downloads need bandwidth, but no CPU, while builds do not need
> bandwidth, but need CPU. With this patch, guix will be able to download
> substitutes while building unrelated packages. Currently, guix needs to
> wait for the download to finish before proceeding to the build. This
> should reduce the time of guix commands that need to build and download
> things at the same time.
>
> What do you think?

Looks like a neat improvement! Could you provide a follow-up to
Ludovic's review? It seems not much is missing (minor cosmetic changes
to commit messages + code and more importantly, the accompanying
documentation update).

Thank you!

Maxim
J
J
Julien Lepiller wrote on 21 Nov 2021 23:49
Re: [bug#39728] [PATCH v2] Allow parallel downloads and builds
(name . Pierre Neidhardt)(address . mail@ambrevar.xyz)
20211121234941.32724b68@tachikoma.lepiller.eu
Le Wed, 26 Feb 2020 11:36:32 +0100,
Pierre Neidhardt <mail@ambrevar.xyz> a écrit :

Toggle quote (10 lines)
> Thank you so much for this, Julien!
>
> There was a thread on this topic on the mailing list:
> https://lists.gnu.org/archive/html/guix-devel/2019-11/msg00002.html
> (could not find the first email :p).
>
> There were a couple other issues that were mentioned there.
> This patch would be a first step towards more parallelization!
>

Hi!

After so long, I managed to find the time to go over the comments and
improve my patches. I tested the new daemon for a bit, and it's working
as expected so far :D
From d8b39af21d97dc3f0d3057ceb7ba91a93ff8d3ec Mon Sep 17 00:00:00 2001
Message-Id: <d8b39af21d97dc3f0d3057ceb7ba91a93ff8d3ec.1637534792.git.julien@lepiller.eu>
In-Reply-To: <3dee3844b6da1d70b883391f5b2d23e331d6a5ad.1637534792.git.julien@lepiller.eu>
References: <3dee3844b6da1d70b883391f5b2d23e331d6a5ad.1637534792.git.julien@lepiller.eu>
From: Julien Lepiller <julien@lepiller.eu>
Date: Sun, 21 Nov 2021 23:26:11 +0100
Subject: [PATCH 2/2] guix: Support specifying max download jobs.

* guix/store.scm (set-build-options): Optionally send max-download-jobs.
* guix/scripts/build.scm (set-build-options-from-command-line)
(%standard-build-options): Support `--max-downloads`
* doc/guix.texi (Common Build Options): Document it.
---
doc/guix.texi | 6 ++++++
guix/scripts/build.scm | 8 ++++++++
guix/store.scm | 5 +++++
3 files changed, 19 insertions(+)

Toggle diff (68 lines)
diff --git a/doc/guix.texi b/doc/guix.texi
index b8de53c53b..0afefbd416 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -10846,6 +10846,12 @@ Common Build Options
guix-daemon, @option{--max-jobs}}, for details about this option and the
equivalent @command{guix-daemon} option.
+@item --max-downloads=@var{n}
+@itemx -D @var{n}
+Allow at most @var{n} download jobs in parallel. @xref{Invoking
+guix-daemon, @option{--max-downloads}}, for details about this option and the
+equivalent @command{guix-daemon} option.
+
@item --debug=@var{level}
Produce debugging output coming from the build daemon. @var{level} must be an
integer between 0 and 5; higher means more verbose output. Setting a level of
diff --git a/guix/scripts/build.scm b/guix/scripts/build.scm
index 97e2f5a167..0d0199eccd 100644
--- a/guix/scripts/build.scm
+++ b/guix/scripts/build.scm
@@ -207,6 +207,7 @@ (define (set-build-options-from-command-line store opts)
#:rounds (assoc-ref opts 'rounds)
#:build-cores (assoc-ref opts 'cores)
#:max-build-jobs (assoc-ref opts 'max-jobs)
+ #:max-download-jobs (assoc-ref opts 'max-downloads)
#:fallback? (assoc-ref opts 'fallback?)
#:use-substitutes? (assoc-ref opts 'substitutes?)
#:substitute-urls (assoc-ref opts 'substitute-urls)
@@ -316,6 +317,13 @@ (define %standard-build-options
(let ((c (false-if-exception (string->number arg))))
(if c
(apply values (alist-cons 'max-jobs c result) rest)
+ (leave (G_ "not a number: '~a' option argument: ~a~%")
+ name arg)))))
+ (option '(#\D "max-downloads") #t #f
+ (lambda (opt name arg result . rest)
+ (let ((c (false-if-exception (string->number arg))))
+ (if c
+ (apply values (alist-cons 'max-downloads c result) rest)
(leave (G_ "not a number: '~a' option argument: ~a~%")
name arg)))))))
diff --git a/guix/store.scm b/guix/store.scm
index 7388953d15..6b5b9262b1 100644
--- a/guix/store.scm
+++ b/guix/store.scm
@@ -803,6 +803,7 @@ (define* (set-build-options server
(verbosity 0)
rounds ;number of build rounds
max-build-jobs
+ max-download-jobs
timeout
max-silent-time
(offload? #t)
@@ -896,6 +897,10 @@ (define* (set-build-options server
`(("build-max-jobs"
. ,(number->string max-build-jobs)))
'())
+ ,@(if max-download-jobs
+ `(("download-max-jobs"
+ . ,(number->string max-download-jobs)))
+ '())
,@(if build-cores
`(("build-cores" . ,(number->string build-cores)))
'())
--
2.33.1
L
L
Ludovic Courtès wrote on 25 Nov 2021 13:53
(name . Julien Lepiller)(address . julien@lepiller.eu)
87ilwge6re.fsf@gnu.org
Hello,

Julien Lepiller <julien@lepiller.eu> skribis:

Toggle quote (4 lines)
> After so long, I managed to find the time to go over the comments and
> improve my patches. I tested the new daemon for a bit, and it's working
> as expected so far :D

On a recent daemon, have you seen cases where having multiple downloads
in parallel speeds things up?

The analysis in
suggests that at the time you first submitted this patch, substitution
speed (which is different from raw download speed) was often CPU-bound.
This is no longer the case, meaning that downloads should now be
network-bound or almost.

Thanks,
Ludo’.
J
J
Julien Lepiller wrote on 25 Nov 2021 14:01
(name . Ludovic Courtès)(address . ludo@gnu.org)
20211125140145.1c00decc@tachikoma.lepiller.eu
Le Thu, 25 Nov 2021 13:53:25 +0100,
Ludovic Courtès <ludo@gnu.org> a écrit :

Toggle quote (21 lines)
> Hello,
>
> Julien Lepiller <julien@lepiller.eu> skribis:
>
> > After so long, I managed to find the time to go over the comments
> > and improve my patches. I tested the new daemon for a bit, and it's
> > working as expected so far :D
>
> On a recent daemon, have you seen cases where having multiple
> downloads in parallel speeds things up?
>
> The analysis in
> <https://guix.gnu.org/en/blog/2021/getting-bytes-to-disk-more-quickly/>
> suggests that at the time you first submitted this patch, substitution
> speed (which is different from raw download speed) was often
> CPU-bound. This is no longer the case, meaning that downloads should
> now be network-bound or almost.
>
> Thanks,
> Ludo’.

I would still say yes, because the output from berlin is often much
less than my throughput. With multiple downloads in parallel it at
least feels quicker, probably because I can download at full speed.

In any case, I see often a build start while downloads are in progress,
so I think it's still a win if you can get a few derivations built
while waiting for a big download to finish at the same time :)

At some point we might want to prioritize builds/downloads that help
unlock as much builds as possible early, so we don't have builds
waiting for downloads.
L
L
Ludovic Courtès wrote on 26 Nov 2021 11:16
(name . Julien Lepiller)(address . julien@lepiller.eu)
87r1b39q8f.fsf@gnu.org
Hi!

Julien Lepiller <julien@lepiller.eu> skribis:

Toggle quote (4 lines)
> I would still say yes, because the output from berlin is often much
> less than my throughput. With multiple downloads in parallel it at
> least feels quicker, probably because I can download at full speed.

It would be nice to measure that because like I wrote, I think we’re
pretty much network-bound these days, at least with zstd and
uncompressed downloads.

Toggle quote (4 lines)
> In any case, I see often a build start while downloads are in progress,
> so I think it's still a win if you can get a few derivations built
> while waiting for a big download to finish at the same time :)

True! Overlapping downloads and builds sounds like a good idea.

Toggle quote (4 lines)
> At some point we might want to prioritize builds/downloads that help
> unlock as much builds as possible early, so we don't have builds
> waiting for downloads.

Right now the daemon starts with substitutes and builds afterwards.

BTW, we’re assuming downloads = substitutes in this whole discussion,
but we could/should take fixed-output derivations into account too.

I’ll take a closer look later on…

Thanks,
Ludo’.
?