[For the most part the prior history of my notes is not
important so they are mostly omitted this time.]

It looks like my notes about official bulk package builds
taking longer may be from observations of more than one
distinct issue, one leading to a very rough factor of 2
and the other not leading to anything like such.

I'd reported that main-arm64-default was taking very roughly
2x as long to do its official bulk -a -c (from scratch)
style build. This is what got me to classify the time
increase as rather significant. It was the first thing that
I'd noticed that started my looking around and biased my
interpretation in later looking.

The recent information for main-arm64-default was:

> Just for reference for official main-arm64-default bulk -c -a (from
> scratch) builds:
> 
> 
> p25bf3a3260c7_s680d34896c3 queued 36447
> and has built 15523 and has 19479 remaining, 134:23:16 so far
> (will have built up to 15523+19479 == 35002 when done, if it finishes)
> 
> So: 12 to 13 days (around 300 hrs) as an estimate.
> 
> 
> The prior longest main-arm64-default official build that completed:
> p02dd5021d6f9_s717adecbbb5 queued 36466
> and had built 34853 and had     0 remaining, 163:20:35
> 
> So: 6.8 days or so.
> 
> Overall: very roughly doubling the overall time when the "for
> real" context does not apply.

It turns out that the above may well be essentially independent
of the pkg 2.1.0 related time changes. I did a local test of
building my usual aarch64 ports from scratch prior to updating
the ports tree to have pkg 2.1.0 instead on 2.0.6 . I then
updated to use an updated ports tree that has pkg 2.1.0 and
did a test for that context.

I got nothing remotely like a factor of 2:

pkg 2.0.6 based /usr/ports/ :
[01:04:57] [release-aarch64-default] [2025-04-06_12h23m09s] [committing] Time: 
01:04:46
           Queued: 264 Inspected: 0 Ignored: 0 Built: 264 Failed: 0 Skipped: 0 
Fetched: 0 Remaining: 0

vs.

pkg 2.1.0 based /usr/ports-alt/ :
[01:07:28] [release-aarch64-alt] [2025-04-06_14h16m21s] [committing] Time: 
01:07:27
           Queued: 265 Inspected: 0 Ignored: 0 Built: 265 Failed: 0 Skipped: 0 
Fetched: 0 Remaining: 0


So: 2 min 31 sec or so difference for overall somewhat over an
hour, i.e., 151 sec or so. That is under 1 sec per package
built.

At 1 sec or so per package for more like 34853 packages,
that would be more like 9.68 hrs or so added overall.
(Something I should have noticed and reported earlier.)
That may well be more like what is going on for pkg 2.1.0
related extra time.

The test was in an apple silicon M4 MAX context under Parallels
on macOS. My build configuration is more biased to allowing
high load averages than the official builds are as well. Also:

Host OSVERSION: 1500034
Jail OSVERSION: 1402000

So: Host was before 1500035 (which may not be significant).
Also, it is a NO-DEBUG based personal build of the kernel that
had been booted. That build was based on use of
-mcpu=cortex-a76 . The booted world was of an official PkgBase
install. The poudriere jail was also via an official PkgBase
build rather than a personal build:

# poudriere jail -l
JAILNAME         VERSION         OSVERSION ARCH          METHOD  TIMESTAMP      
     PATH
release-aarch64  14.2-RELEASE-p1           aarch64       pkgbase 2025-03-12 
21:11:39 /usr/local/poudriere/jails/release-aarch64
. . .

(Note: "poudriere jail -j release-aarch64 -u" does not seem
to update the "-p1" part of VERSION.)


For aarch64, only main-arm64-default ( p25bf3a3260c7_s680d34896c3 )
has started a from scratch build. The closest aarch64 alternative
is the large build:

134arm64-quarterly ( 359bbf7fc5af ) that queued 28018
and has built 12870 and has 13677 remaining: 92:24:15

That suggests 180+ hours overall for less than a
from-scratch build. That is more than the prior
largest time for a completed 134arm64-quarterly
build: 125:58:32 --and by far more than 10 hours.

134arm64-quarterly ( 2cbed7722168 ) that queued 36335
and built 34903 and had 0 remaining: 125:58:32

So there being an aarch64 timing issue is not limited to
debug kernel builds, although the factor may be somewhat
smaller than 2 for a non-debug kernel and world being
used.


===
Mark Millard
marklmi at yahoo.com


Reply via email to