Re: RPi 4 build time

From: Mark Millard via freebsd-arm <>
Date: Fri, 21 May 2021 13:58:36 -0700
On 2021-May-21, at 13:07, Evgeniy Khramtsov via freebsd-arm <freebsd-arm at> wrote:

> How long are compile times for aarch64 8 GB RPi? It is especially
> interesting to know about overclocked results. I guess buildworld time
> would describe it well, but any heavy port (ex. rust) would also be great.

To get useful figures may require specification of more context.
For example, building rust uses over 17 GiBytes of temporary file
space. This suggests that its build time may be very dependent on
the media in use. Also the configuration of building ports in
parallel and/or allowing a port builder to potentially have an
ready-to-run process for each of the 4 cores makes for large

Also, for buildworld, there is a large difference for when a
bootstrap set of clang/llvm materials is built vs. when that
extra clang/llvm material does not build (even if the normal
llvm material are built).

There are also issues like if ccache is in use and is providing
a signficant amount of hot-cache results. (I do not use ccache.)
The same sort of thing apply to META_MODE use and rebuilds: was
the build "from scratch" vs. just a partial rebuild? (I do use

I've not done lang/rust builds on a RPi4B. (And, for ports, I
normally allow multiple ports to build at once, each allowed
to have a ready-to-run process per core.)

As for buildworld/buildkernel "from scratch", that I have done
and recorded some figures:


make[1]: "/usr/fbsd/mm-src/Makefile.inc1" line 339: SYSTEM_COMPILER: Determined that CC=cc matches the source tree.  Not bootstrapping a cross-compiler.
make[1]: "/usr/fbsd/mm-src/Makefile.inc1" line 344: SYSTEM_LINKER: Determined that LD=ld matches the source tree.  Not bootstrapping a cross-linker.

I use a USB3 SSD to hold the UFS file system, swap space,
and the msdos file system used in booting. No microsd card
use at all. The USB3 SSD seems to be fairly effective at
making the storage-I/O performant for the RPi4B context.

And oddity of my context is I have the code generation set
up to tune for cortex-a72 specifically. Both the system doing
the build and the built system were based on such tuning.

ENVIRONMENT: -mcpu=cortex-a72 RPi4B _at_ 2000 MHz, hw.physmem:8464072704 :
( arm_freq=2000, sdram_freq_min=3200, force_turbo=1 )

World build completed on Fri Mar 26 19:10:11 PDT 2021
World built in 22491 seconds, ncpu: 4, make -j4
Kernel build for GENERIC-NODBG completed on Fri Mar 26 19:38:33 PDT 2021
Kernel(s)  GENERIC-NODBG built in 1702 seconds, ncpu: 4, make -j4

So World+Kernel took somewhat under 6 hrs 45 min to build.

# ~/ 
merge-base: 7381bbee29df959e88ec59866cf2878263e7f3b2
merge-base: CommitDate: 2021-03-12 20:29:42 +0000
def0058cc690 (HEAD -> mm-src) mm-src snapshot for mm's patched build in git context.
7381bbee29df (freebsd/main, freebsd/HEAD, pure-src, main) cam: Run all XPT_ASYNC ccbs in a dedicated thread
FreeBSD RPi4B 14.0-CURRENT FreeBSD 14.0-CURRENT mm-src-n245445-def0058cc690 GENERIC-NODBG  arm64 aarch64 1400005 1400005

I've gotten very similar time frames from builds that used
a ZFS file system on a USB3 SSD of the same type instead.

Mark Millard
marklmi at
( went
away in early 2018-Mar)
Received on Fri May 21 2021 - 20:58:36 UTC

Original text of this message