From nobody Mon Feb 10 22:22:17 2025 X-Original-To: freebsd-pkg@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4YsJwk0LMcz5mtVb for ; Mon, 10 Feb 2025 22:22:30 +0000 (UTC) (envelope-from diego@bsd.com.br) Received: from mail-yw1-x1131.google.com (mail-yw1-x1131.google.com [IPv6:2607:f8b0:4864:20::1131]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4YsJwj5bvrz3fc9 for ; Mon, 10 Feb 2025 22:22:29 +0000 (UTC) (envelope-from diego@bsd.com.br) Authentication-Results: mx1.freebsd.org; none Received: by mail-yw1-x1131.google.com with SMTP id 00721157ae682-6f666c94285so43669477b3.3 for ; Mon, 10 Feb 2025 14:22:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsd.com.br; s=capeta; t=1739226148; x=1739830948; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=j1iYiMZ9VrBRjnM0CkmQf+O3Csr4e96U4QT7oCJXZvs=; b=Hxt9qWxebJENPAmdgafhpC+XYq7hNxGtAr/dEweqoFRuywUMh/SCW6tWBdT40OLg9k 0BSh9RcKh89DoRgoBaeD3b1ce+mbMrxTeV2474dB3xqt9rbxOxNB8mW2ns1LFO2+Ng5g OzUnGicMxp6JBnzrfDwUBDd0BzIx+hY4ciLc0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739226148; x=1739830948; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=j1iYiMZ9VrBRjnM0CkmQf+O3Csr4e96U4QT7oCJXZvs=; b=dFkOepMe1h53DeCygKhSR4CODRwPPBseFKawDPfYM3zdV9oR6sH0Eu0SaOqu3GrkEJ JHhuzWaGcDJ0JGwVCSQ2iicq/c9ECD2DCnO5B+pR4I8mAsCwI34hXTP25/WYKTEv1G52 lVPaDCFR0f08MezJzyduhNjzh7kXhIJZgvAlJez0WhbFkYKXheHgAPYrMtLgg5KFaL5p WKQgsUFz6wBfySl/4K7qYn3gSRn4keqPzRH4CF7hDkYhzKTx0iNiKQsXaRq7OdCg7sNt AnbaKg+j25Twf4c4ZZUvmUQCBidmFWEp3oepslT7tuQQnMd5LRWJDmMYQinLZbMeXFKg yMYg== X-Gm-Message-State: AOJu0Yz2X/h6AIhldeBA0SFKE73wQmYXEZvvF4J7bJIH2/C3Wu/oWEiD RCkirhJWe/yQT0FWWJIGMJzWAyl9zxULK+NHEUp5pStuuNEGARlX05oAMKbVT+rIG0PB8Nl6BDK 4Ko18+8GieWM9GHdRmGcQkgWH122sWMTpMjta X-Gm-Gg: ASbGnct3u6ndUUYLldyjWd0E3fwxjIw5xZlZ6m00L6rqrvfSP2IrWuanB80VwNmJmP2 h4XlMo8MY1iNt4nUsqIuFyXb6LmIn5ZWPLcWoEb5dpaX/u48AmTs4cFtKAicpdO/B2o/98RMd X-Google-Smtp-Source: AGHT+IF8nyDvAlxyjv8tgpHkr8uNQfWi+ef0YQ+j/KTR0yDf+asixdg290wdyY4hheEJioAUkNdUvSFdxPrsu1jQbHk= X-Received: by 2002:a05:690c:c14:b0:6ef:9dbe:9f82 with SMTP id 00721157ae682-6f9b2981af4mr140008717b3.29.1739226148184; Mon, 10 Feb 2025 14:22:28 -0800 (PST) List-Id: Binary package management and package tools discussion List-Archive: https://lists.freebsd.org/archives/freebsd-pkg List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-pkg@FreeBSD.org MIME-Version: 1.0 References: <566D4C18-A850-4394-A717-4E61FF0EA129.ref@yahoo.com> <566D4C18-A850-4394-A717-4E61FF0EA129@yahoo.com> In-Reply-To: <566D4C18-A850-4394-A717-4E61FF0EA129@yahoo.com> From: Diego Linke Date: Mon, 10 Feb 2025 19:22:17 -0300 X-Gm-Features: AWEUYZk7e-cMT0LHQOrDI2jXBckzsL5WkVpOhm5HpDaNWjpU-92r0vbaa2enIag Message-ID: Subject: Re: arm64 pkg building is taking longer To: Mark Millard Cc: FreeBSD-pkg@freebsd.org Content-Type: multipart/alternative; boundary="000000000000bf48f3062dd12456" X-Rspamd-Queue-Id: 4YsJwj5bvrz3fc9 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] --000000000000bf48f3062dd12456 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=AFPM Mark Millard wr= ote: > Diego Linke wrote on > Date: Mon, 10 Feb 2025 12:07:19 UTC : > > > I noticed that ARM64 packages take a few days longer to build and becom= e > > 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) upda= te > > 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=E2=80=99m aware that I can set up my own package build infrastruc= ture using > > Poudriere and am considering it as a fallback option. However, I=E2=80= =99d 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. > > > > =3D=3D=3D > Mark Millard > marklmi at yahoo.com > > --000000000000bf48f3062dd12456 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Mark,

Thank you very much= for the detailed explanation.=C2=A0

I appreciate = the insights into the differences in build resources and the constraints af= fecting ARM64. I also appreciate that security updates are already prioriti= zed within the available resources.=C2=A0

Regards,
=

Diego L= inke


On Mon, Feb 10, 2025 at 6:48=E2=80=AFPM Mark Millard <marklmi@yahoo.com> wrote:
Diego Linke <diego_at_bsd.com.br<= /a>> wrote on
Date: Mon, 10 Feb 2025 12:07:19 UTC :

> I noticed that ARM64 packages take a few days longer to build and beco= me
> available on the official FreeBSD servers compared to AMD64 and i386.<= br>
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) upd= ate
> 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 no= t
> 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, especiall= y 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=E2=80=99m aware that I can set up my own package build infrastru= cture using
> Poudriere and am considering it as a fallback option. However, I=E2=80= =99d 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.



=3D=3D=3D
Mark Millard
marklmi at yahoo.com

--000000000000bf48f3062dd12456--