Date: Sun, 6 Apr 2025 16:55:41 -0700 From: Mark Millard <marklmi@yahoo.com> To: Baptiste Daroussin <bapt@FreeBSD.org>, Konstantin Belousov <kib@freebsd.org>, Warner Losh <imp@bsdimp.com> Cc: FreeBSD Current <freebsd-current@freebsd.org>, FreeBSD Mailing List <freebsd-ports@freebsd.org> Subject: Re: UPDATE: pkg 2.1.0 looks to be making official bulk builds of packages take much longer [it is more complicated then that for aarch64] Message-ID: <5B20A794-DA42-4F46-A80C-9A262C0382B5@yahoo.com> In-Reply-To: <366E27FD-FA5B-4BF8-B6C4-6C495DB289C5@yahoo.com> References: <8E2FBAD3-EF6F-4D99-A340-21F8FD19AE0F@yahoo.com> <FA9C7841-6D61-4285-AC6D-46328CBC56D2@yahoo.com> <C7BBEC76-228F-4F9E-A5F9-86E9F53372FD@yahoo.com> <D3C2F75D-838B-47E9-B125-71104A3C16EA@yahoo.com> <CD66A7B2-422B-40FE-BB17-145032DBA46F@FreeBSD.org> <84FBBAF8-025E-4B9D-9797-51735567A8DB@yahoo.com> <B295D1CB-E47D-4359-A79A-986213E7AFCE@yahoo.com> <366E27FD-FA5B-4BF8-B6C4-6C495DB289C5@yahoo.com>
index | next in thread | previous in thread | raw e-mail
[Correcting a dumb mistaken reference.] On Apr 6, 2025, at 16:43, Mark Millard <marklmi@yahoo.com> wrote: > [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, Actually, 134arm64-quarterly also has Host 1500035 : Host OSVERSION: 1500035 Jail OSVERSION: 1304000 and I've no clue if the 1500035 is a debug version vs. not. > although the factor may be somewhat > smaller than 2 for a non-debug kernel and world being > used. === Mark Millard marklmi at yahoo.comhelp
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5B20A794-DA42-4F46-A80C-9A262C0382B5>