Date: Mon, 10 Feb 2025 19:22:17 -0300 From: Diego Linke <diego@bsd.com.br> To: Mark Millard <marklmi@yahoo.com> Cc: FreeBSD-pkg@freebsd.org Subject: Re: arm64 pkg building is taking longer Message-ID: <CAG5Cswq=Uab9p_UYtrYxr%2BuQHREg8ua0HJCG68d5YRo2ACL_ug@mail.gmail.com> In-Reply-To: <566D4C18-A850-4394-A717-4E61FF0EA129@yahoo.com>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] Hi Mark, Thank you very much for the detailed explanation. I appreciate the insights into the differences in build resources and the constraints affecting ARM64. I also appreciate that security updates are already prioritized within the available resources. Regards, Diego Linke On Mon, Feb 10, 2025 at 6:48 PM Mark Millard <marklmi@yahoo.com> wrote: > Diego Linke <diego_at_bsd.com.br> wrote on > Date: Mon, 10 Feb 2025 12:07:19 UTC : > > > I noticed that ARM64 packages take a few days longer to build and become > > available on the official FreeBSD servers compared to AMD64 and i386. > > The amd64 systems are generally faster and there are > a lot more of them used as package builders. > > There are only 3 aarch64 build systems: ampere[1-3]. > > By contrast, there are 10 amd64 build systems, 3 being > fairly modern and vastly faster than the ampere*'s > (far more hardware threads, for example). > > ampere1 cycles through building and distributing: > 141arm64-quarterly > 141releng-armv7-quarterly > 1341arm64-quarterly > 134releng-armv7-quarterly > > amd64 systems do not build that many variations on the > same machine: in fact each normally only builds one > variation, no waiting for other cycle members to > finish. > > As each takes longer, the next time it gets back to the > same type of build, it is likely that far more packages > that need to be built (compared to the analogous amd64 > context). It is not as extreme for quarterly as it is > for default (a.k.a. latest). > > ampere3 is similar (default here is a.k.a. latest): > 141arm64-default > 141releng-armv7-default > 1341arm64-default > 134releng-armv7-default > > ampere3 likely builds the most per poudriere bulk run > compared to ampere1 above, taking the largest to get > back to the next build of the same member of the cycle. > > ampere2 has only 2 cycle members (as stands, main is 15.0): > main-arm64-default > main-armv7-default > > So that makes 10 separate variations overall, spread > over the 3 ampere*'s. > > amd64/i386 has 10 separate variations as well, but > 1 per amd64 system that does the type build. > 141amd64-quarterly , 141amd64-default , and > 141i386-default are what get the fastest 3 builder > machines. > > > For example, last Monday, Mat committed the Bind 9.2 (dns/bind920) update > > to 9.20.5 in the quarterly branch, which has two security fixes. This > > update was available on amd64 and i386 2 days later. It's still not > > available (after 7 days) for ARM64. > > Expected sort of result, given the resources available to put > to use. > > > Could we prioritize building packages with security updates, especially > for > > the quarterly branch? > > Already done: The more and bigger "default" builds do not > complete for the machine time on ampere1. Mixed on the > same machine the "default" builds would further delay the > quarterly builds. > > > Is anyone aware of any initiatives to improve this > > process? > > Unless the aarch64/armv7 system resources are considered > as part of the "process": it is not basically a process > problem. (I'm not intending to imply that "no optimization > is possible", just that such is not likely to lead to > a large change of scale for how long things take in > order to reach similar times to amd64 now takes.) > > > PS: I’m aware that I can set up my own package build infrastructure using > > Poudriere and am considering it as a fallback option. However, I’d like > to > > explore whether we can improve the process for everyone. > > That last note repeats here: it is not basically a process > problem for what is the major constraint. > > > > === > Mark Millard > marklmi at yahoo.com > > [-- Attachment #2 --] <div dir="ltr"><div>Hi Mark,</div><div><br></div><div>Thank you very much for the detailed explanation. </div><div><br></div><div>I appreciate the insights into the differences in build resources and the constraints affecting ARM64. I also appreciate that security updates are already prioritized within the available resources. </div><div><br>Regards,</div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><br>Diego Linke<br></div></div></div></div></div></div></div><br></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Mon, Feb 10, 2025 at 6:48 PM Mark Millard <<a href="mailto:marklmi@yahoo.com">marklmi@yahoo.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Diego Linke <<a href="http://diego_at_bsd.com.br" rel="noreferrer" target="_blank">diego_at_bsd.com.br</a>> wrote on<br> Date: Mon, 10 Feb 2025 12:07:19 UTC :<br> <br> > I noticed that ARM64 packages take a few days longer to build and become<br> > available on the official FreeBSD servers compared to AMD64 and i386.<br> <br> The amd64 systems are generally faster and there are<br> a lot more of them used as package builders.<br> <br> There are only 3 aarch64 build systems: ampere[1-3].<br> <br> By contrast, there are 10 amd64 build systems, 3 being<br> fairly modern and vastly faster than the ampere*'s<br> (far more hardware threads, for example).<br> <br> ampere1 cycles through building and distributing:<br> 141arm64-quarterly<br> 141releng-armv7-quarterly<br> 1341arm64-quarterly<br> 134releng-armv7-quarterly<br> <br> amd64 systems do not build that many variations on the<br> same machine: in fact each normally only builds one<br> variation, no waiting for other cycle members to<br> finish.<br> <br> As each takes longer, the next time it gets back to the<br> same type of build, it is likely that far more packages<br> that need to be built (compared to the analogous amd64<br> context). It is not as extreme for quarterly as it is<br> for default (a.k.a. latest).<br> <br> ampere3 is similar (default here is a.k.a. latest):<br> 141arm64-default<br> 141releng-armv7-default<br> 1341arm64-default<br> 134releng-armv7-default<br> <br> ampere3 likely builds the most per poudriere bulk run<br> compared to ampere1 above, taking the largest to get<br> back to the next build of the same member of the cycle.<br> <br> ampere2 has only 2 cycle members (as stands, main is 15.0):<br> main-arm64-default<br> main-armv7-default<br> <br> So that makes 10 separate variations overall, spread<br> over the 3 ampere*'s.<br> <br> amd64/i386 has 10 separate variations as well, but<br> 1 per amd64 system that does the type build.<br> 141amd64-quarterly , 141amd64-default , and<br> 141i386-default are what get the fastest 3 builder<br> machines.<br> <br> > For example, last Monday, Mat committed the Bind 9.2 (dns/bind920) update<br> > to 9.20.5 in the quarterly branch, which has two security fixes. This<br> > update was available on amd64 and i386 2 days later. It's still not<br> > available (after 7 days) for ARM64.<br> <br> Expected sort of result, given the resources available to put<br> to use.<br> <br> > Could we prioritize building packages with security updates, especially for<br> > the quarterly branch?<br> <br> Already done: The more and bigger "default" builds do not<br> complete for the machine time on ampere1. Mixed on the<br> same machine the "default" builds would further delay the<br> quarterly builds.<br> <br> > Is anyone aware of any initiatives to improve this<br> > process?<br> <br> Unless the aarch64/armv7 system resources are considered<br> as part of the "process": it is not basically a process<br> problem. (I'm not intending to imply that "no optimization<br> is possible", just that such is not likely to lead to<br> a large change of scale for how long things take in<br> order to reach similar times to amd64 now takes.)<br> <br> > PS: I’m aware that I can set up my own package build infrastructure using<br> > Poudriere and am considering it as a fallback option. However, I’d like to<br> > explore whether we can improve the process for everyone.<br> <br> That last note repeats here: it is not basically a process<br> problem for what is the major constraint.<br> <br> <br> <br> ===<br> Mark Millard<br> marklmi at <a href="http://yahoo.com" rel="noreferrer" target="_blank">yahoo.com</a><br> <br> </blockquote></div>home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAG5Cswq=Uab9p_UYtrYxr%2BuQHREg8ua0HJCG68d5YRo2ACL_ug>