Re: RPi 4 build time [13.0-RELEASE -> 13.0-RELEASE-p1 META_MODE example]

From: Mark Millard via freebsd-arm <>
Date: Wed, 26 May 2021 22:42:40 UTC

On 2021-May-22, at 19:05, Mark Millard via freebsd-arm <freebsd-arm at> wrote:

> On 2021-May-22, at 18:36, Mark Millard via freebsd-arm <freebsd-arm at> wrote:
>> On 2021-May-22, at 18:23, tech-lists <tech-lists at> wrote:
>>> On Sat, May 22, 2021 at 04:51:31PM -0700, Mark Millard via freebsd-arm wrote:
>>>> In general these figures are approximations of the low
>>>> bound on a buildworld that is a (near) no-op but is
>>>> not frequently approached in my normal activity. But
>>>> it is rare for me to update the source tree again
>>>> and rebuild after only a few source commits after
>>>> what was originally rebuilt. For such, sub-half hour
>>>> rebuilds can certainly occur via META_MODE use.
>>>> The context happened to be the ZFS based one in all
>>>> cases. Still no ccache use.
>>> That's wild. I have to look at meta mode. 
>>> My use case though mostly involves building/updating ports with
>>> poudriere, and I'm happy it can use ccache.
>>> Am I right in thinking meta mode is a buildworld/kernel thing only? I've
>>> only heard of it; I know nothing about it.
>> Yep: buildworld buildkernel only.
>> META_MODE does not help for after a "rm -rf /usr/obj/*"
>> sort of clean-out. It just attempts to avoid rebuilding
>> materials already present that are sufficient. (It still
>> builds more than is strictly necessary: Some of the
>> dependency tracking tracks things that do not actually
>> imply needing a file rebuild. This is why installworld
>> to the live system ends up leading to a larger rebuild
>> later.)
> I should have also mentioned the other side of
> META_MODE: It is there to also be sure to rebuild
> things that do need to be rebuilt. Its rebuilding
> more than necessary generally avoids ending up with
> insufficient/inaccurate rebuilds. Between ending
> up with false positives vs. false negatives, it
> has a definite bias.

An example use of META_MODE: The buildworld buildkernel
to be used for updating 13.0-RELEASE based to to
13.0-RELEASE-p1 based (old build still around to
start from):

World build completed on Wed May 26 14:52:43 PDT 2021
World built in 612 seconds, ncpu: 4, make -j4

Kernel build for GENERIC-NODBG-CA72 completed on Wed May 26 15:20:36 PDT 2021
Kernel(s)  GENERIC-NODBG-CA72 built in 1673 seconds, ncpu: 4, make -j4

It shows a mix: buildworld did not have much to
rebuild but buildkernel did have a lot to build.
Overall: somewhat under 40 minutes for buildworld
buildkernel to complete.

After installing and rebooting, my 13_0R-CA72-nodbg
boot environment is at:

# uname -apKU
FreeBSD CA72_4c8G_ZFS 13.0-RELEASE-p1 FreeBSD 13.0-RELEASE-p1 #1 releng/13.0-n244744-8023e729a521-dirty: Wed May 26 15:20:08 PDT 2021     root@CA72_4c8G_ZFS:/usr/obj/BUILDs/13_0R-CA72-nodbg-clang/usr/13_0R-src/arm64.aarch64/sys/GENERIC-NODBG-CA72  arm64 aarch64 1300139 1300139

# ~/ 
branch: releng/13.0
merge-base: 8023e729a52192f89e539de760df194a70a91fda
merge-base: CommitDate: 2021-05-26 20:36:52 +0000
8023e729a521 (HEAD -> releng/13.0, freebsd/releng/13.0) Add UPDATING entries and bump version
n244744 (--first-parent --count for merge-base)

(buildworld buildkernel was via a ssh session. In
some contexts using the serial console causes more
time to be taken, just to display all the output
text during the activity. installworld is an
example for my contexts.)

Mark Millard
marklmi at
( went
away in early 2018-Mar)