unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Mathieu Othacehe <othacehe@gnu.org>
To: Jonathan Brielmaier <jonathan.brielmaier@web.de>
Cc: Guix-devel <guix-devel@gnu.org>
Subject: Re: ARM build machines
Date: Tue, 28 Jul 2020 14:55:13 +0200	[thread overview]
Message-ID: <874kpriytq.fsf@gnu.org> (raw)
In-Reply-To: 3308cccb-0f9f-6499-b948-3062a8a81ec8@web.de


Hello Jonathan,

Thanks a lot for this nice report. Let me summarize a bit the situation
first, before commenting on your findings.

On our main "berlin" build farm, we have currently a few aarch64
machines:

* overdrive.guixsd.org
* dover.guix.info
* dmitri.tobias.gr
* sergei.tobias.gr

We are also emulating aarch64 and armhf builds on around 20 x86_64
machines (hydra-guix-101 ... hydra-guix-120 roughly).

Regarding the physical machines, the overdrive seems like a modest
machine (in comparison to the x86 machines we have), and I don't know
about the other 3 ones.

For the emulation, even though it's way way slower than real hardware,
those 20 machines are really powerful and should be able to bring us
good substitutes coverage.

The current situation is that due to Cuirass/offloading issues such as
[1], our build farm is most of the time idle. Given our computation
power, we should be able to bake much more substitutes I think.

Maybe we could also take advantage of the build-coordinator Christopher
is implementing (+ Guix daemon RPC's over HTTP) to make sure that we are
able to deal with a distributed build farm efficiently.

Now the question I'm asking myself is: could the ARM substitutes
situation be solved by improving our CI software stack, or do we really
need more hardware?

Hard to answer right now, but maybe the best way to proceed would be to
make sure that we are using the hardware we have close to its limit
first and then consider buying more.

> Neither VPS nor dedicated build machines for ARM are cheap, if they are
> decent powerful. As a first step I could try to reach out Linaro if they
> are willing to provide us some VMs.

Yep, that would be great to explore this option!

Concerning the other options you proposed, they are indeed expensive and
as I said, at this point, our CI software stack would not be able to use
it efficiently, which would be sad.

What do other people think?

Thanks,

Mathieu

[1]: https://issues.guix.gnu.org/34033



  reply	other threads:[~2020-07-28 12:55 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-28 10:31 ARM build machines Jonathan Brielmaier
2020-07-28 12:55 ` Mathieu Othacehe [this message]
2020-08-24 14:42   ` Improving CI throughput Ludovic Courtès
2020-08-24 14:57     ` John Soo
2020-08-25 13:32     ` Mathieu Othacehe
2020-08-25 17:44       ` Ricardo Wurmus
2020-08-28 13:51       ` Ludovic Courtès

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

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=874kpriytq.fsf@gnu.org \
    --to=othacehe@gnu.org \
    --cc=guix-devel@gnu.org \
    --cc=jonathan.brielmaier@web.de \
    /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 public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).