unofficial mirror of guix-devel@gnu.org 
 help / color / 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
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 index

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-28 10:31 Jonathan Brielmaier
2020-07-28 12:55 ` Mathieu Othacehe [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

  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

unofficial mirror of guix-devel@gnu.org 

Archives are clonable:
	git clone --mirror https://yhetil.org/guix-devel/0 guix-devel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 guix-devel guix-devel/ https://yhetil.org/guix-devel \
		guix-devel@gnu.org
	public-inbox-index guix-devel

Example config snippet for mirrors

Newsgroups are available over NNTP:
	nntp://news.yhetil.org/yhetil.gnu.guix.devel
	nntp://news.gmane.io/gmane.comp.gnu.guix.devel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git