From: "Ludovic Courtès" <ludo@gnu.org>
To: Andreas Enge <andreas@enge.fr>
Cc: 63412@debbugs.gnu.org
Subject: bug#63412: Topological sorting in cuirass
Date: Sun, 29 Oct 2023 18:01:20 +0100 [thread overview]
Message-ID: <87jzr5747z.fsf@gnu.org> (raw)
In-Reply-To: <ZFtspPexmg3YM/ug@jurong> (Andreas Enge's message of "Wed, 10 May 2023 12:06:28 +0200")
Hi,
Andreas Enge <andreas@enge.fr> skribis:
> This is a wishlist bug, but it is important for architectures where we
> are currently short on build power, and where this issue can stall builds
> and waste an arbitrary amount of build power.
>
> Cuirass should sort builds and only offload derivations for which all
> inputs are available.
Cuirass has two build backends: talking to the build daemon, and using
the ZeroMQ-based “remote worker” protocol. In practice we use the
latter, which fixes scalability issues with the former.
The worker protocol implements work stealing: workers periodically send
messages to “remote server” asking for work. Said server replies with a
derivation for one of the systems the worker supports; that derivation
is chosen among the “builds” whose dependencies have all been
successfully built.
And here’s the trick: the server is doing the right thing, but it has a
partial view. Namely, the server sees “builds” rather than
“derivations”. “Builds” are the things explicitly declared in the
jobset. If you have a declared build for GCC, but no build for MPC and
MPFR, then the server will consider that GCC has zero non-built
dependencies, even though MPFR and MPC may still need to be built.
Having ‘remote-worker’ operate on derivations rather than builds would
address this impedance mismatch, though there are complications (there
are bits of the database schema that amalgamate build/derivation).
Food for thought!
Ludo’.
prev parent reply other threads:[~2023-10-29 17:02 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-10 10:06 bug#63412: Topological sorting in cuirass Andreas Enge
2023-05-10 13:59 ` Dr. Arne Babenhauserheide
2023-10-29 17:01 ` Ludovic Courtès [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87jzr5747z.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=63412@debbugs.gnu.org \
--cc=andreas@enge.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.