Date: Fri, 15 Mar 2024 09:59:45 +0100 From: Oliver Epper <oliver.epper@gmail.com> To: Mark Millard <marklmi@yahoo.com> Cc: FreeBSD Mailing List <freebsd-ports@freebsd.org>, FreeBSD ARM List <freebsd-arm@freebsd.org>, Nuno Teixeira <eduardo@freebsd.org> Subject: Re: 4-core arm armv7-package-building configuration notes, on RPi4B (aarch64) and OrangePi+2ed (armv7), poudriere-devel based Message-ID: <CAP8tsuR4JhJipPrVWD1RY4VendfTJQiyyqF%2BKKNTa4N0PWyrRA@mail.gmail.com> In-Reply-To: <867B8EBD-820C-41B6-9B5D-307AD9506343@yahoo.com> References: <9D19D8E3-5B72-4006-9296-C7D74E670A12@yahoo.com> <867B8EBD-820C-41B6-9B5D-307AD9506343@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--0000000000005d4c600613af3b3c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I can only suggest deploying a Mac Mini M1 with qemu using Apple HVF as a poudriere server for aarch64. See https://oliver-epper.de/posts/poudriere-on-m1-mac/ I never had success with qemu emulation on amd64 and the Mac Mini builds rust and llvm without problems. I don't think I'd like to wait for these packages to build on a pi. greetings Oliver Am Fr., 15. M=C3=A4rz 2024 um 09:39 Uhr schrieb Mark Millard <marklmi@yahoo= .com>: > On Mar 12, 2024, at 23:57, Mark Millard <marklmi@yahoo.com> wrote: > > > This note's structure: > > > > 1st: Package-build time frame summaries. > > (But I note some hardware points that are repeated later as well.) > > > > 2nd: Configuration points common to both RPi4B and OrangePi+2ed context= s. > > > > 3rd: Configuration points unique to the RPi4B context. > > > > 4th: Configuration points unique to the OrangePi+2ed context. > > > > > > 1st: Package-build time Summaries follow. > > (Note: the detail order of package builds is not the same.) > > (Examples are visiable in these summaries.) > > > > > > RPi4B: cortex-a72 (aarch64) with cortex-a7 (armv7) support, 2 GHz > (overclocked), 8 GiBytes RAM, USB3 > > [00:25:32] [01] [00:13:33] Finished lang/perl5.36 | perl5-5.36.3_1: > Success > > [01:58:13] [02] [00:44:25] Finished devel/icu | icu-74.2,1: Success > > [03:14:00] [02] [00:21:28] Finished lang/ruby31 | ruby-3.1.4_1,1: Succe= ss > > [03:33:51] [01] [02:21:22] Finished devel/cmake-core | > cmake-core-3.28.3: Success > > [23:12:47] [02] [19:06:01] Finished lang/rust | rust-1.76.0: Success > > [1D:00:14:46] [02] [00:55:46] Finished devel/binutils@native | > binutils-2.40_5,1: Success > > (Note: start of visible ordering differences:) > > [1D:03:07:32] [02] [00:58:03] Finished devel/arm-none-eabi-gcc | > arm-none-eabi-gcc-11.3.0_3: Success > > [1D:03:42:09] [01] [1D:00:08:13] Finished devel/llvm18@default | > llvm18-18.1.0.r3: Success > > [1D:04:45:14] [02] [01:35:29] Finished lang/gcc13 | gcc13-13.2.0_4: > Success > > [1D:05:21:43] [01] [01:39:13] Finished devel/boost-libs | > boost-libs-1.84.0: Success > > [1D:05:43:24] [01] [00:21:33] Finished textproc/source-highlight | > source-highlight-3.1.9_9: Success > > [1D:05:47:01] [02] [00:44:22] Finished devel/aarch64-none-elf-gcc | > aarch64-none-elf-gcc-11.3.0_3: Success > > [1D:07:23:25] [02] [01:21:04] Finished devel/gdb@py39 | gdb-14.1_2: > Success > > [1D:07:58:37] [01] [01:19:55] Finished devel/freebsd-gcc13@armv7 | > armv7-gcc13-13.2.0_1: Success > > [1D:07:58:43] Stopping 2 builders > > [main-CA7-default] [2024-03-11_15h30m14s] [committing] Queued: 265 > Built: 265 Failed: 0 Skipped: 0 Ignored: 0 Fetched: 0 Tobuild: 0 > Time: 1D:07:58:46 > > > > Note: 4364Mi MaxObs(Act+Wir+Lndry+SwapUsed) ("MaxObs": short for > "Maximum Observed") > > Note: SwapUsed maximum: 0 (none used). > > > > So, for an 8 GiByte RAM RPI4B, RAM+SWAP configured to be 38 GiBytes or > so: > > Estmate: 38.0 GiBytes/4.3 GiBytes approx.=3D=3D 8.8 > > Result: Lots of margin for builds that use more RAM+SWAP. > > > > So, for an 4 GiByte RAM RPI4B, RAM+SWAP configured to be 18 GiBytes or > so: > > Estimate: 18.0 GiBytes/4.3 GiBytes approx.=3D=3D 4.1 > > Result: Also lots of margin for builds that use more RAM+SWAP. > > I did the experiment of trying PARALLEL_JOBS=3D3 instead of > PARALLEL_JOBS=3D2 , still MAKE_JOBS_NUMBER_LIMIT=3D3 . It took > a little longer: > > [1D:08:52:32] Stopping 3 builders > [main-CA7-default] [2024-03-13_16h27m18s] [committing] Queued: 265 Built: > 265 Failed: 0 Skipped: 0 Ignored: 0 Fetched: 0 Tobuild: 0 Time= : > 1D:08:52:35 > > (As the load averages are significantly more than the > available hardware thread count and vary significantly, > comparing individual package build times is not > particularly useful. So I'm not reporting any example > times for packages.) > > At some point I'll likely try the PARALLEL_JOBS=3D2 > MAKE_JOBS_NUMBER_LIMIT=3D3 combination on a RPI4B that has > 4 GiBytes of RAM. I really need the memory pressure > involved in significant paging to get reasonable estimates > for RAM+SWAP requiments, avoiding just ending up with a > large Inact accumulation with an unknown mix of dirty pages > and clean pages. > > But, I'll likely try the RPi5 (8 GiBytes) first, now > that the RPi5 EDK2 has fixed what the problem was that lead > to unreliable USB I/O for UEFI/ACPI. (I'll likely use an > artifact build since the release build looks to not be > present yet.) > > > OrangePi+2ed: cortex-a7 armv7, 1GHz, 4 cores, 2 GiBytes RAM, USB2: > > [01:51:31] [01] [01:00:07] Finished lang/perl5.36 | perl5-5.36.3_1: > Success > > [08:55:35] [02] [03:08:09] Finished devel/icu | icu-74.2,1: Success > > [13:17:38] [02] [01:28:32] Finished lang/ruby31 | ruby-3.1.4_1,1: Succe= ss > > [14:17:44] [01] [09:20:55] Finished devel/cmake-core | > cmake-core-3.28.3: Success > > [4D:01:03:43] [02] [3D:08:48:53] Finished lang/rust | rust-1.76.0: > Success > > [4D:06:26:24] [02] [03:09:35] Finished devel/binutils@native | > binutils-2.40_5,1: Success > > (Note: start of visible ordering differences:) > > [4D:14:54:31] [02] [03:38:55] Finished devel/aarch64-none-elf-gcc | > aarch64-none-elf-gcc-11.3.0_3: Success > > [4D:16:13:00] [01] [4D:01:55:03] Finished devel/llvm18@default | > llvm18-18.1.0.r3: Success > > [4D:18:05:58] [02] [03:11:00] Finished devel/arm-none-eabi-gcc | > arm-none-eabi-gcc-11.3.0_3: Success > > [4D:23:00:13] [01] [06:46:06] Finished devel/boost-libs | > boost-libs-1.84.0: Success > > [5D:00:16:39] [01] [01:15:53] Finished textproc/source-highlight | > source-highlight-3.1.9_9: Success > > [5D:01:17:24] [02] [07:10:52] Finished lang/gcc13 | gcc13-13.2.0_4: > Success > > [5D:09:38:14] [01] [05:56:48] Finished devel/freebsd-gcc13@armv7 | > armv7-gcc13-13.2.0_1: Success > > [5D:10:18:58] [02] [05:44:02] Finished devel/gdb@py39 | gdb-14.1_2: > Success > > [5D:10:31:56] Stopping 2 builders > > [main-CA7-default] [2024-03-06_03h15m10s] [committing] Queued: 265 > Built: 265 Failed: 0 Skipped: 0 Ignored: 0 Fetched: 0 Tobuild: 0 > Time: 5D:10:31:55 > > > > (So, a little over 4 days longer than the RPi4B example above.) > > > > Note: 2794Mi MaxObs(Act+Wir+Lndry+SwapUsed) ("MaxObs": short for > "Maximum Observed") > > > > > > 2nd: Configuration points common to both the RPi4B and the > > OrangePi+2ed contexts. > > > > ports-mgmt/poudriere-devel is used to build the packages. > > > > devel/llvm18 options: using BE_NATIVE and omitting MLIR. > > (What I normally build for armv7 and aarch64 targetting.) > > > > Also, ports-mgmt/poudriere-devel omits the QEMU option, > > as is normal for me. > > > > 265 packages are built, including pkg. It is the same > > 265 pacakges across contexts. (The order of the builds > > does vary.) > > > > /usr/local/etc/poudriere.conf has . . . > > > > NO_ZFS=3Dyes > > PARALLEL_JOBS=3D2 > > ALLOW_MAKE_JOBS=3Dyes > > MAX_EXECUTION_TIME=3D432000 > > NOHANG_TIME=3D432000 > > MAX_EXECUTION_TIME_EXTRACT=3D14400 > > MAX_EXECUTION_TIME_INSTALL=3D14400 > > MAX_EXECUTION_TIME_PACKAGE=3D57600 > > MAX_EXECUTION_TIME_DEINSTALL=3D14400 > > > > NOTE: MAKE_JOBS_NUMBER_LIMIT is used to constrain > > what ALLOW_MAKE_JOBS does but is not set the > > same across the contexts. > > > > /etc/fstab does not specify any tmpfs use or the > > like: avoids competing for RAM+SWAP. > > > > poudriere armv7 jail worlds are duplicates of each > > other across the different media. Those worlds are > > from a personal buildworld based on using > > -mcpu=3Dcortex-a7 for the code generation. The package > > builds also use that. > > > > /boot/loader.conf has . . . > > > > # Delay when persistent low free RAM leads to > > # Out Of Memory killing of processes: > > vm.pageout_oom_seq=3D120 > > > > Heatsinks and fans for keeping things cool over the > > sustained build activity. > > > > > > 3rd: Configuration points unique to the RPi4B context. > > > > /usr/local/etc/poudriere.conf has . . . > > > > USE_TMPFS=3D"data" > > > > (Based on the larger RAM and RAM+SWAP and that it > > does not grow to be huge for the likes of lang/rust .) > > > > /usr/local/etc/poudriere.d/make.conf has . . . > > > > MAKE_JOBS_NUMBER_LIMIT=3D3 > > > > (Based on the larger RAM and RAM+SWAP.) This does mean > > that the 3 load averages can be 6+ at times on the 4 > > hardware thread system while both ports being built are > > respecting the limit. Some ports do not fully respect > > the limit the whole time. This can make build-times > > a somewhat messier comparison than one might hope across > > the contexts. But for the specifics here, things should > > be clear enough. > > > > RAM =3D=3D 8 GiBytes > > RAM+SWAP =3D=3D 38 GiBytes > > (Note aarch64 allows a larger RAM multiplier limit without > > warning of potential swap-related mistuning: "total > > configured swap (? pages) exceeds maximum recommended > > amount (? pages)" with "increase kern.maxswzone or reduce > > amount of swap".) > > > > 5.1V 3.5A power supply, so a little extra margin for current. > > > > /boot/efi/config.txt has: > > > > over_voltage=3D6 > > arm_freq=3D2000 > > sdram_freq_min=3D3200 > > force_turbo=3D1 > > (Reliable operation, with margin, on the mix of v1.1, v1.4, and v1.5 > > RPi4B's that I have access to, 8 total.) > > > > So: 2 GHz overclocking, using a fixed rate. > > > > USB3 media: U2 Optane 960 GB media via a powered USB3 adaptor. > > > > Kernel has: "arm64: improve UVA layout for 32bit processes" > > ( main's 967022aa5aa6 ). So an armv7 process can be somewhat > > over 3 GiBytes for its address space. > > > > Boot aarch64 env: a PkgBase world and kernel.GENERIC-NODEBUG pair. > > FYI: > > > > # uname -apKU > > FreeBSD aarch64-main-pkgs 15.0-CURRENT FreeBSD 15.0-CURRENT > main-n268514-61b88a230bac GENERIC-NODEBUG arm64 aarch64 1500014 1500014 > > > > > > 4th: Configuration points unique to the OrangePi+2ed context. > > > > /usr/local/etc/poudriere.conf has . . . > > > > USE_TMPFS=3Dno > > > > (Based on the smaller RAM --and smaller RAM+SWAP for avoiding > > potential-mistuning notices.) > > > > /usr/local/etc/poudriere.d/make.conf has . . . > > > > MAKE_JOBS_NUMBER_LIMIT=3D2 > > > > (Based on the smaller RAM --and smaller RAM+SWAP for avoiding > > potential-mistuning notices-- but wanting to still have margin > > for bigger peak RAM+SWAP use than the example happens to do.) > > > > RAM =3D=3D 2 GiBytes > > RAM+SWAP =3D=3D 5.6 GiBytes > > (Note armv7 has a smaller RAM multiplier limit without > > warning of potential swap-related mistuning: "total > > configured swap (? pages) exceeds maximum recommended > > amount (? pages)" with "increase kern.maxswzone or reduce > > amount of swap".) > > > > In /etc/rc.conf I have: > > > > if [ "`sysctl -i -n hw.fdt.model`" =3D=3D "Xunlong Orange Pi Plus 2E" ]= ; then > > sysctl dev.cpu.0.freq=3D1008 > /dev/null > > fi > > > > In other words: a fixed 1GHz or so clock rate is used. > > > > USB2 media: Actually USB3 media that also supports USB2 > > use. 1 TB Samsung Touch T7 (NVMe based) via a powered hub, > > a USB3-capable one. > > > > > > > > Side note: > > > > I've no clue how to judge any tradeoff consequences for > > "increase kern.maxswzone" for judging reasonableness of > > such an action. > > > > > > =3D=3D=3D > Mark Millard > marklmi at yahoo.com > > > --0000000000005d4c600613af3b3c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">I can only suggest deploying a Mac Mini M1 with qemu using= Apple HVF as a poudriere server for aarch64.<div>See=C2=A0<a href=3D"https= ://oliver-epper.de/posts/poudriere-on-m1-mac/">https://oliver-epper.de/post= s/poudriere-on-m1-mac/</a></div><div><br></div><div>I never had success wit= h qemu emulation on amd64 and the Mac Mini builds rust and llvm without pro= blems. I don't think I'd like to wait for these packages to build o= n a pi.</div><div><br></div><div>greetings</div><div>Oliver</div></div><br>= <div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">Am Fr., 15= . M=C3=A4rz 2024 um 09:39=C2=A0Uhr schrieb Mark Millard <<a href=3D"mail= to:marklmi@yahoo.com">marklmi@yahoo.com</a>>:<br></div><blockquote class= =3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo= rder-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">= On Mar 12, 2024, at 23:57, Mark Millard <<a href=3D"mailto:marklmi@yahoo= .com" target=3D"_blank">marklmi@yahoo.com</a>> wrote:<br> <br> > This note's structure:<br> > <br> > 1st: Package-build time frame summaries.<br> >=C2=A0 =C2=A0 =C2=A0(But I note some hardware points that are repeated = later as well.)<br> > <br> > 2nd: Configuration points common to both RPi4B and OrangePi+2ed contex= ts.<br> > <br> > 3rd: Configuration points unique to the RPi4B context.<br> > <br> > 4th: Configuration points unique to the OrangePi+2ed context.<br> > <br> > <br> > 1st: Package-build time Summaries follow.<br> > (Note: the detail order of package builds is not the same.)<br> > (Examples are visiable in these summaries.)<br> > <br> > <br> > RPi4B: cortex-a72 (aarch64) with cortex-a7 (armv7) support, 2 GHz (ove= rclocked), 8 GiBytes RAM, USB3<br> > [00:25:32] [01] [00:13:33] Finished lang/perl5.36 | perl5-5.36.3_1: Su= ccess<br> > [01:58:13] [02] [00:44:25] Finished devel/icu | icu-74.2,1: Success<br= > > [03:14:00] [02] [00:21:28] Finished lang/ruby31 | ruby-3.1.4_1,1: Succ= ess<br> > [03:33:51] [01] [02:21:22] Finished devel/cmake-core | cmake-core-3.28= .3: Success<br> > [23:12:47] [02] [19:06:01] Finished lang/rust | rust-1.76.0: Success<b= r> > [1D:00:14:46] [02] [00:55:46] Finished devel/binutils@native | binutil= s-2.40_5,1: Success<br> > (Note: start of visible ordering differences:)<br> > [1D:03:07:32] [02] [00:58:03] Finished devel/arm-none-eabi-gcc | arm-n= one-eabi-gcc-11.3.0_3: Success<br> > [1D:03:42:09] [01] [1D:00:08:13] Finished devel/llvm18@default | llvm1= 8-18.1.0.r3: Success<br> > [1D:04:45:14] [02] [01:35:29] Finished lang/gcc13 | gcc13-13.2.0_4: Su= ccess<br> > [1D:05:21:43] [01] [01:39:13] Finished devel/boost-libs | boost-libs-1= .84.0: Success<br> > [1D:05:43:24] [01] [00:21:33] Finished textproc/source-highlight | sou= rce-highlight-3.1.9_9: Success<br> > [1D:05:47:01] [02] [00:44:22] Finished devel/aarch64-none-elf-gcc | aa= rch64-none-elf-gcc-11.3.0_3: Success<br> > [1D:07:23:25] [02] [01:21:04] Finished devel/gdb@py39 | gdb-14.1_2: Su= ccess<br> > [1D:07:58:37] [01] [01:19:55] Finished devel/freebsd-gcc13@armv7 | arm= v7-gcc13-13.2.0_1: Success<br> > [1D:07:58:43] Stopping 2 builders<br> > [main-CA7-default] [2024-03-11_15h30m14s] [committing] Queued: 265 Bui= lt: 265 Failed: 0=C2=A0 =C2=A0Skipped: 0=C2=A0 =C2=A0Ignored: 0=C2=A0 =C2= =A0Fetched: 0=C2=A0 =C2=A0Tobuild: 0=C2=A0 =C2=A0 Time: 1D:07:58:46<br> > <br> > Note: 4364Mi MaxObs(Act+Wir+Lndry+SwapUsed) ("MaxObs":=C2=A0= short for "Maximum Observed")<br> > Note: SwapUsed maximum: 0 (none used).<br> > <br> > So, for an 8 GiByte RAM RPI4B, RAM+SWAP configured to be 38 GiBytes or= so:<br> > Estmate: 38.0 GiBytes/4.3 GiBytes approx.=3D=3D 8.8<br> > Result: Lots of margin for builds that use more RAM+SWAP.<br> > <br> > So, for an 4 GiByte RAM RPI4B, RAM+SWAP configured to be 18 GiBytes or= so:<br> > Estimate: 18.0 GiBytes/4.3 GiBytes approx.=3D=3D 4.1<br> > Result: Also lots of margin for builds that use more RAM+SWAP.<br> <br> I did the experiment of trying PARALLEL_JOBS=3D3 instead of<br> PARALLEL_JOBS=3D2 , still MAKE_JOBS_NUMBER_LIMIT=3D3 . It took<br> a little longer:<br> <br> [1D:08:52:32] Stopping 3 builders<br> [main-CA7-default] [2024-03-13_16h27m18s] [committing] Queued: 265 Built: 2= 65 Failed: 0=C2=A0 =C2=A0Skipped: 0=C2=A0 =C2=A0Ignored: 0=C2=A0 =C2=A0Fetc= hed: 0=C2=A0 =C2=A0Tobuild: 0=C2=A0 =C2=A0 Time: 1D:08:52:35<br> <br> (As the load averages are significantly more than the<br> available hardware thread count and vary significantly,<br> comparing individual package build times is not<br> particularly useful. So I'm not reporting any example<br> times for packages.)<br> <br> At some point I'll likely try the PARALLEL_JOBS=3D2<br> MAKE_JOBS_NUMBER_LIMIT=3D3 combination on a RPI4B that has<br> 4 GiBytes of RAM. I really=C2=A0 need the memory pressure<br> involved in significant paging to get reasonable estimates<br> for RAM+SWAP requiments, avoiding just ending up with a<br> large Inact accumulation with an unknown mix of dirty pages<br> and clean pages.<br> <br> But, I'll likely try the RPi5 (8 GiBytes) first, now<br> that the RPi5 EDK2 has fixed what the problem was that lead<br> to unreliable USB I/O for UEFI/ACPI. (I'll likely use an<br> artifact build since the release build looks to not be<br> present yet.)<br> <br> > OrangePi+2ed: cortex-a7 armv7, 1GHz, 4 cores, 2 GiBytes RAM, USB2:<br> > [01:51:31] [01] [01:00:07] Finished lang/perl5.36 | perl5-5.36.3_1: Su= ccess<br> > [08:55:35] [02] [03:08:09] Finished devel/icu | icu-74.2,1: Success<br= > > [13:17:38] [02] [01:28:32] Finished lang/ruby31 | ruby-3.1.4_1,1: Succ= ess<br> > [14:17:44] [01] [09:20:55] Finished devel/cmake-core | cmake-core-3.28= .3: Success<br> > [4D:01:03:43] [02] [3D:08:48:53] Finished lang/rust | rust-1.76.0: Suc= cess<br> > [4D:06:26:24] [02] [03:09:35] Finished devel/binutils@native | binutil= s-2.40_5,1: Success<br> > (Note: start of visible ordering differences:)<br> > [4D:14:54:31] [02] [03:38:55] Finished devel/aarch64-none-elf-gcc | aa= rch64-none-elf-gcc-11.3.0_3: Success<br> > [4D:16:13:00] [01] [4D:01:55:03] Finished devel/llvm18@default | llvm1= 8-18.1.0.r3: Success<br> > [4D:18:05:58] [02] [03:11:00] Finished devel/arm-none-eabi-gcc | arm-n= one-eabi-gcc-11.3.0_3: Success<br> > [4D:23:00:13] [01] [06:46:06] Finished devel/boost-libs | boost-libs-1= .84.0: Success<br> > [5D:00:16:39] [01] [01:15:53] Finished textproc/source-highlight | sou= rce-highlight-3.1.9_9: Success<br> > [5D:01:17:24] [02] [07:10:52] Finished lang/gcc13 | gcc13-13.2.0_4: Su= ccess<br> > [5D:09:38:14] [01] [05:56:48] Finished devel/freebsd-gcc13@armv7 | arm= v7-gcc13-13.2.0_1: Success<br> > [5D:10:18:58] [02] [05:44:02] Finished devel/gdb@py39 | gdb-14.1_2: Su= ccess<br> > [5D:10:31:56] Stopping 2 builders<br> > [main-CA7-default] [2024-03-06_03h15m10s] [committing] Queued: 265 Bui= lt: 265 Failed: 0=C2=A0 =C2=A0Skipped: 0=C2=A0 =C2=A0Ignored: 0=C2=A0 =C2= =A0Fetched: 0=C2=A0 =C2=A0Tobuild: 0=C2=A0 =C2=A0 Time: 5D:10:31:55<br> > <br> > (So, a little over 4 days longer than the RPi4B example above.)<br> > <br> > Note: 2794Mi MaxObs(Act+Wir+Lndry+SwapUsed) ("MaxObs":=C2=A0= short for "Maximum Observed")<br> > <br> > <br> > 2nd: Configuration points common to both the RPi4B and the<br> >=C2=A0 =C2=A0 =C2=A0OrangePi+2ed contexts.<br> > <br> > ports-mgmt/poudriere-devel is used to build the packages.<br> > <br> > devel/llvm18 options: using BE_NATIVE and omitting MLIR.<br> > (What I normally build for armv7 and aarch64 targetting.)<br> > <br> > Also, ports-mgmt/poudriere-devel omits the QEMU option,<br> > as is normal for me.<br> > <br> > 265 packages are built, including pkg. It is the same<br> > 265 pacakges across contexts. (The order of the builds<br> > does vary.)<br> > <br> > /usr/local/etc/poudriere.conf has . . .<br> > <br> > NO_ZFS=3Dyes<br> > PARALLEL_JOBS=3D2<br> > ALLOW_MAKE_JOBS=3Dyes<br> > MAX_EXECUTION_TIME=3D432000<br> > NOHANG_TIME=3D432000<br> > MAX_EXECUTION_TIME_EXTRACT=3D14400<br> > MAX_EXECUTION_TIME_INSTALL=3D14400<br> > MAX_EXECUTION_TIME_PACKAGE=3D57600<br> > MAX_EXECUTION_TIME_DEINSTALL=3D14400<br> > <br> > NOTE: MAKE_JOBS_NUMBER_LIMIT is used to constrain<br> >=C2=A0 =C2=A0 =C2=A0 what ALLOW_MAKE_JOBS does but is not set the<br> >=C2=A0 =C2=A0 =C2=A0 same across the contexts.<br> > <br> > /etc/fstab does not specify any tmpfs use or the<br> > like: avoids competing for RAM+SWAP.<br> > <br> > poudriere armv7 jail worlds are duplicates of each<br> > other across the different media. Those worlds are<br> > from a personal buildworld based on using<br> > -mcpu=3Dcortex-a7 for the code generation. The package<br> > builds also use that.<br> > <br> > /boot/loader.conf has . . .<br> > <br> > # Delay when persistent low free RAM leads to<br> > # Out Of Memory killing of processes:<br> > vm.pageout_oom_seq=3D120<br> > <br> > Heatsinks and fans for keeping things cool over the<br> > sustained build activity.<br> > <br> > <br> > 3rd: Configuration points unique to the RPi4B context.<br> > <br> > /usr/local/etc/poudriere.conf has . . .<br> > <br> > USE_TMPFS=3D"data"<br> > <br> > (Based on the larger RAM and RAM+SWAP and that it<br> > does not grow to be huge for the likes of lang/rust .)<br> > <br> > /usr/local/etc/poudriere.d/make.conf has . . .<br> > <br> > MAKE_JOBS_NUMBER_LIMIT=3D3<br> > <br> > (Based on the larger RAM and RAM+SWAP.) This does mean<br> > that the 3 load averages can be 6+ at times on the 4<br> > hardware thread system while both ports being built are<br> > respecting the limit. Some ports do not fully respect<br> > the limit the whole time. This can make build-times<br> > a somewhat messier comparison than one might hope across<br> > the contexts. But for the specifics here, things should<br> > be clear enough.<br> > <br> > RAM =3D=3D 8 GiBytes<br> > RAM+SWAP =3D=3D 38 GiBytes<br> > (Note aarch64 allows a larger RAM multiplier limit without<br> > warning of potential swap-related mistuning: "total<br> > configured swap (? pages) exceeds maximum recommended<br> > amount (? pages)" with "increase kern.maxswzone or reduce<br= > > amount of swap".)<br> > <br> > 5.1V 3.5A power supply, so a little extra margin for current.<br> > <br> > /boot/efi/config.txt has:<br> > <br> > over_voltage=3D6<br> > arm_freq=3D2000<br> > sdram_freq_min=3D3200<br> > force_turbo=3D1<br> > (Reliable operation, with margin, on the mix of v1.1, v1.4, and v1.5<b= r> > RPi4B's that I have access to, 8 total.)<br> > <br> > So: 2 GHz overclocking, using a fixed rate.<br> > <br> > USB3 media: U2 Optane 960 GB media via a powered USB3 adaptor.<br> > <br> > Kernel has: "arm64: improve UVA layout for 32bit processes"<= br> > ( main's 967022aa5aa6 ). So an armv7 process can be somewhat<br> > over 3 GiBytes for its address space.<br> > <br> > Boot aarch64 env: a PkgBase world and kernel.GENERIC-NODEBUG pair.<br> > FYI:<br> > <br> > # uname -apKU<br> > FreeBSD aarch64-main-pkgs 15.0-CURRENT FreeBSD 15.0-CURRENT main-n2685= 14-61b88a230bac GENERIC-NODEBUG arm64 aarch64 1500014 1500014<br> > <br> > <br> > 4th: Configuration points unique to the OrangePi+2ed context.<br> > <br> > /usr/local/etc/poudriere.conf has . . .<br> > <br> > USE_TMPFS=3Dno<br> > <br> > (Based on the smaller RAM --and smaller RAM+SWAP for avoiding<br> > potential-mistuning notices.)<br> > <br> > /usr/local/etc/poudriere.d/make.conf has . . .<br> > <br> > MAKE_JOBS_NUMBER_LIMIT=3D2<br> > <br> > (Based on the smaller RAM --and smaller RAM+SWAP for avoiding<br> > potential-mistuning notices-- but wanting to still have margin<br> > for bigger peak RAM+SWAP use than the example happens to do.)<br> > <br> > RAM =3D=3D 2 GiBytes<br> > RAM+SWAP =3D=3D 5.6 GiBytes<br> > (Note armv7 has a smaller RAM multiplier limit without<br> > warning of potential swap-related mistuning: "total<br> > configured swap (? pages) exceeds maximum recommended<br> > amount (? pages)" with "increase kern.maxswzone or reduce<br= > > amount of swap".)<br> > <br> > In /etc/rc.conf I have:<br> > <br> > if [ "`sysctl -i -n hw.fdt.model`" =3D=3D "Xunlong Oran= ge Pi Plus 2E" ]; then<br> > sysctl dev.cpu.0.freq=3D1008 > /dev/null<br> > fi<br> > <br> > In other words: a fixed 1GHz or so clock rate is used.<br> > <br> > USB2 media: Actually USB3 media that also supports USB2<br> > use. 1 TB Samsung Touch T7 (NVMe based) via a powered hub,<br> > a USB3-capable one.<br> > <br> > <br> > <br> > Side note:<br> > <br> > I've no clue how to judge any tradeoff consequences for<br> > "increase kern.maxswzone" for judging reasonableness of<br> > such an action.<br> > <br> <br> <br> <br> =3D=3D=3D<br> Mark Millard<br> marklmi at <a href=3D"http://yahoo.com" rel=3D"noreferrer" target=3D"_blank= ">yahoo.com</a><br> <br> <br> </blockquote></div> --0000000000005d4c600613af3b3c--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAP8tsuR4JhJipPrVWD1RY4VendfTJQiyyqF%2BKKNTa4N0PWyrRA>