From nobody Sat Nov 5 09:28:51 2022 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N4Bym2T1Vz4hGF0 for ; Sat, 5 Nov 2022 09:29:20 +0000 (UTC) (envelope-from archimedes.gaviola@gmail.com) Received: from mail-yb1-xb35.google.com (mail-yb1-xb35.google.com [IPv6:2607:f8b0:4864:20::b35]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4N4Byl6RYWz475M for ; Sat, 5 Nov 2022 09:29:19 +0000 (UTC) (envelope-from archimedes.gaviola@gmail.com) Received: by mail-yb1-xb35.google.com with SMTP id e123so4068503ybh.11 for ; Sat, 05 Nov 2022 02:29:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=sQqahxOSQapUklk+S4E8dlsF+Trat29UhVx/OeNVYc0=; b=j6ZQFPdoGCaVUHP7gPBENxHqSkOsMw3gTVXHi+x6k0GaKhd6Dn91X9WtEWotfLiZ9G 41ybU0pJoq5togAgf1AzoFqPB0B63SjPDHMVQempYkfqzzBMji/4T51eHKmjVhKKDJDo 0cb0ikLAIQA58tgsdwVAREdu20aZ2TLJaar1llVeQ/1QZT1ZW4BOe7RX58bKACsGi/Ns LiwQSSBK2qCVxJGWJIYWqJ58/mv3chyXkBkNHPy4Ym7zVtGxblfMSw3CyyhYKE+Bs75Q outYG3rPy2XSBvQhGkKnP5uMsKciaPvFf/kt/PEQwVBsydmrvXrduUzs1/c4FnFoBEHk XapA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=sQqahxOSQapUklk+S4E8dlsF+Trat29UhVx/OeNVYc0=; b=awGJSCvL3Vkxe24RtXXZdhISArmSRY0uRN78o1tyK9gz2EgH+sqcPP+/K21Gqnzw75 tKSP2YOzU80HR5bA7lAw7DQkGZdTYktFnMfB9+/+bEYDSgLBMdl48XucZxjlJNRCutxq YVKeRJNxX1nH9WhV3ZhFtBXyb9keRneGNads1rMBpzRjU/DGEueTtdd944aCmxUJzJbk UBQ/lMNMO7PeENb3k2UwsZDWUczyOKWJlyS3WLoshUCuUBY3TNhO9VaCh4ACyr4IqY/H VwdDkOvzwMVCPtq09kM2ljbwS0qUxNcdiLTO8P2tBhggK470F4rcJdKH78OoskizSolK YtQw== X-Gm-Message-State: ACrzQf3Zp7vKqaUAV3svdF5y5f7cg6Isleh0V477534JZxJpDHUjeTeS 3hK3EzETSg+cxI/dbmmjizRZ2S/tHZCj8GPGryY+WML8Gvc= X-Google-Smtp-Source: AMsMyM5COAsXk3D0PeKUwqKyo0ZVnL1DPKNZjbDqZe5tLdAlFUu1e0mqGXMApiWM5CgCFel59sba+0iBQvrqnlyz7Bc= X-Received: by 2002:a25:3f86:0:b0:6bc:998:873e with SMTP id m128-20020a253f86000000b006bc0998873emr39834872yba.152.1667640559235; Sat, 05 Nov 2022 02:29:19 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <84376CC9-B991-4BF3-AF5F-0AA09CB28339.ref@yahoo.com> <84376CC9-B991-4BF3-AF5F-0AA09CB28339@yahoo.com> In-Reply-To: From: Archimedes Gaviola Date: Sat, 5 Nov 2022 17:28:51 +0800 Message-ID: Subject: Re: 14.0-CURRENT failed to reclaim memory error in RPi 3B build To: Mark Millard Cc: freebsd-current Content-Type: multipart/alternative; boundary="00000000000025763905ecb5d31f" X-Rspamd-Queue-Id: 4N4Byl6RYWz475M X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=j6ZQFPdo; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of archimedes.gaviola@gmail.com designates 2607:f8b0:4864:20::b35 as permitted sender) smtp.mailfrom=archimedes.gaviola@gmail.com X-Spamd-Result: default: False [-3.83 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.83)[-0.828]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::b35:from]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2]; RCPT_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_TO(0.00)[yahoo.com]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --00000000000025763905ecb5d31f Content-Type: text/plain; charset="UTF-8" On Thu, Nov 3, 2022 at 7:52 AM Mark Millard wrote: > On 2022-Nov-2, at 14:09, Archimedes Gaviola > wrote: > > > On Mon, Oct 31, 2022 at 1:47 PM Archimedes Gaviola < > archimedes.gaviola@gmail.com> wrote: > > > > . . . > > > > . . . > > > > > > Hi Mark, > > > > Just an update, as kernel and world compilation is ongoing with my RPi3B > system (with swap partition) is doing so far, so good. It already surpassed > the tough part that breaks the compilation process here. > > ... > > > > llvm-tblgen -gen-asm-matcher -I > /usr/src/contrib/llvm-project/llvm/include -I > /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV -d > RISCVGenAsmMatcher.inc.d -o RISCVGenAsmMatcher.inc > /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td > > llvm-tblgen -gen-asm-writer -I > /usr/src/contrib/llvm-project/llvm/include -I > /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV -d > RISCVGenAsmWriter.inc.d -o RISCVGenAsmWriter.inc > /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td > > llvm-tblgen -gen-callingconv -I > /usr/src/contrib/llvm-project/llvm/include -I > /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV -d > RISCVGenCallingConv.inc.d -o RISCVGenCallingConv.inc > /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td > > llvm-tblgen -gen-compress-inst-emitter -I > /usr/src/contrib/llvm-project/llvm/include -I > /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV -d > RISCVGenCompressInstEmitter.inc.d -o RISCVGenCompressInstEmitter.inc > /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td > > llvm-tblgen -gen-dag-isel -I /usr/src/contrib/llvm-project/llvm/include > -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV -d > RISCVGenDAGISel.inc.d -o RISCVGenDAGISel.inc > /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td > > llvm-tblgen -gen-disassembler -I > /usr/src/contrib/llvm-project/llvm/include -I > /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV -d > RISCVGenDisassemblerTables.inc.d -o RISCVGenDisassemblerTables.inc > /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td > > llvm-tblgen -gen-global-isel -I > /usr/src/contrib/llvm-project/llvm/include -I > /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV -d > RISCVGenGlobalISel.inc.d -o RISCVGenGlobalISel.inc > /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td > > llvm-tblgen -gen-instr-info -I > /usr/src/contrib/llvm-project/llvm/include -I > /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV -d > RISCVGenInstrInfo.inc.d -o RISCVGenInstrInfo.inc > /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td > > llvm-tblgen -gen-emitter -I /usr/src/contrib/llvm-project/llvm/include > -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV -d > RISCVGenMCCodeEmitter.inc.d -o RISCVGenMCCodeEmitter.inc > /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td > > llvm-tblgen -gen-pseudo-lowering -I > /usr/src/contrib/llvm-project/llvm/include -I > /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV -d > RISCVGenMCPseudoLowering.inc.d -o RISCVGenMCPseudoLowering.inc > /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td > > llvm-tblgen -gen-register-bank -I > /usr/src/contrib/llvm-project/llvm/include -I > /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV -d > RISCVGenRegisterBank.inc.d -o RISCVGenRegisterBank.inc > /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td > > llvm-tblgen -gen-register-info -I > /usr/src/contrib/llvm-project/llvm/include -I > /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV -d > RISCVGenRegisterInfo.inc.d -o RISCVGenRegisterInfo.inc > /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td > > llvm-tblgen -gen-searchable-tables -I > /usr/src/contrib/llvm-project/llvm/include -I > /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV -d > RISCVGenSearchableTables.inc.d -o RISCVGenSearchableTables.inc > /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td > > llvm-tblgen -gen-subtarget -I > /usr/src/contrib/llvm-project/llvm/include -I > /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV -d > RISCVGenSubtargetInfo.inc.d -o RISCVGenSubtargetInfo.inc > /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td > > llvm-tblgen -gen-searchable-tables -I > /usr/src/contrib/llvm-project/llvm/include -I > /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV -d > RISCVGenSystemOperands.inc.d -o RISCVGenSystemOperands.inc > /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td > > > > Any thoughts why this part is quite a challenge when it comes to memory > usage? The other architectures do not possess such behavior... just curious. > Hi Mark, Sorry for the late response, I got fully occupied at work for the past few days due to deliverables. Thanks for your feedback and further inputs! > I've not done any monitoring of buildworld buildkernel build > activity (RAM use, memory space use, swap partition use over > time) on RPi3B class hardware in a very long time. > It's alright, it so happened that I just observed that behavior on that particular part as it requires more memory than other architectures while compiling. The additional 3.5G swap partition really helps on that part that's why I was so happy that the compilation continued and never broke. Your input of having 3.5G swap allocation is very effective. Even on systems that I have monitored in more recent times, > what I usually monitor tends to be builds with -jN (such as > -j4 fora 4-hardware-thread system). (I once did have an > example of -j3 taking less time than -j4 on a RPi4B. > Wow, this is interesting this -jN. Let me explore this as well. I usually build kernel the old way but recently since I have to include building the world then I need to use the new way. > Basically, the memory subsystem can be saturated without all > the cores being in use. The extra interference made things > take longer.) > Oh I see so it's the reason. > You had listed that you were using the likes of: > > # cd /usr/src ; make KERNCONF=ARM TARGET_ARCH=aarch64 \ > buildkernel buildworld installkernel installworld distribution \ > DESTDIR=/home/freebsd/rpi3b > > I'll note that the standard order of the first 2 is: > > buildworld buildkernel > > This is because buildworld builds some software that > buildkernel does not build for itself but does use. > Okay this is noted, thanks for clarifying and correcting me, I really appreciate it. I'll reflect on the proper build sequence for much efficiency. > There is a kernel-toolchain target for avoiding the > need to do a full buildworld just to buildkernel , so: > > kernel-toolchain buildkernel > > is an expected sequence. > Okay I'll take note of this too. > I do not know how long a from-scratch buildworld > buildkernel without a -jN takes on a RPi3B these > days. If I remember right, for -jN with 1 saw claims about such they were somewhere in the > range 36hr..48hr. There's an ongoing build at the moment, it's already taking 41 hours since I started it. I took another build when I came back home from the office. > But I'm unsure of the specific N > that was in use. Nor do I know the storage media > type(s) involved, for example. I do not remember > any reports for -j1. > I'll try this with RPi 3B. The current build that I have will be my baseline. Use of the likes of: vm.pageout_oom_seq=120 > was essential to such -jN usage on a RPi3B as N > gets larger. Of course, swap partition use for > paging was also essential. > Wow, that's great! I have this vm.pageout_oom_seq=120 configured in my system now based on your previous inputs. Likewise use of: > > vm.swap_enabled=0 > vm.swap_idle_enabled=0 > > can be important to not losing communication > with the RPi3B. Those last 2 are not tunable > but are writable: > > # sysctl -aT | grep swap_ > # sysctl -aW | grep swap_ > vm.swap_enabled: 0 > . . . > vm.swap_idle_enabled: 0 > . . . > > (This means that they have fewer places where > assignments can be made. For example, the > loader can not make the assignments.) > > By contrast, vm.pageout_oom_seq is both > writable and tunable: > > # sysctl -aW | grep oom > . . . > vm.pageout_oom_seq: 120 > . . . > > # sysctl -aT | grep oom > . . . > vm.pageout_oom_seq: 120 > . . . > > (So even the loader can make such assignments.) > Yes, I have these two sysctl parameters configured in the system. Thanks for the details and further inputs. > I'll note that I've no interest in using arm hardware > to build for other types of hardware. So I normally > have the targeting of support for building for other > architectures disabled when I build on aarch64 or > armv7. (Basically, a less complete clang/clang++ > related toolchain ends up being built.) > Ah okay, so you mean to say that you disable these other architectures by declaring and accomplishing it in the /etc/src.conf? I'll provide an update here once the build is done knowing how long it takes to finish. Thanks and best regards, Archimedes --00000000000025763905ecb5d31f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable



On Thu, Nov 3, 2022 at 7:52 AM Mark Millard <marklmi@yahoo.com> wrote:
On 2022-Nov-2, at 14:09= , Archimedes Gaviola <archimedes.gaviola@gmail.com> wrote:

> On Mon, Oct 31, 2022 at 1:47 PM Archimedes Gaviola <archimedes.gaviola@gmail= .com> wrote:
>
> . . .
>
> . . .
>
>
> Hi Mark,
>
> Just an update, as kernel and world compilation is ongoing with my RPi= 3B system (with swap partition) is doing so far, so good. It already surpas= sed the tough part that breaks the compilation process here.
> ...
>
> llvm-tblgen -gen-asm-matcher=C2=A0 -I /usr/src/contrib/llvm-project/ll= vm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=C2=A0 -d = RISCVGenAsmMatcher.inc.d -o RISCVGenAsmMatcher.inc=C2=A0 /usr/src/contrib/l= lvm-project/llvm/lib/Target/RISCV/RISCV.td
> llvm-tblgen -gen-asm-writer=C2=A0 -I /usr/src/contrib/llvm-project/llv= m/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=C2=A0 -d R= ISCVGenAsmWriter.inc.d -o RISCVGenAsmWriter.inc=C2=A0 /usr/src/contrib/llvm= -project/llvm/lib/Target/RISCV/RISCV.td
> llvm-tblgen -gen-callingconv=C2=A0 -I /usr/src/contrib/llvm-project/ll= vm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=C2=A0 -d = RISCVGenCallingConv.inc.d -o RISCVGenCallingConv.inc=C2=A0 /usr/src/contrib= /llvm-project/llvm/lib/Target/RISCV/RISCV.td
> llvm-tblgen -gen-compress-inst-emitter=C2=A0 -I /usr/src/contrib/llvm-= project/llvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV= =C2=A0 -d RISCVGenCompressInstEmitter.inc.d -o RISCVGenCompressInstEmitter.= inc=C2=A0 /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
> llvm-tblgen -gen-dag-isel=C2=A0 -I /usr/src/contrib/llvm-project/llvm/= include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=C2=A0 -d RIS= CVGenDAGISel.inc.d -o RISCVGenDAGISel.inc=C2=A0 /usr/src/contrib/llvm-proje= ct/llvm/lib/Target/RISCV/RISCV.td
> llvm-tblgen -gen-disassembler=C2=A0 -I /usr/src/contrib/llvm-project/l= lvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=C2=A0 -d= RISCVGenDisassemblerTables.inc.d -o RISCVGenDisassemblerTables.inc=C2=A0 /= usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
> llvm-tblgen -gen-global-isel=C2=A0 -I /usr/src/contrib/llvm-project/ll= vm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=C2=A0 -d = RISCVGenGlobalISel.inc.d -o RISCVGenGlobalISel.inc=C2=A0 /usr/src/contrib/l= lvm-project/llvm/lib/Target/RISCV/RISCV.td
> llvm-tblgen -gen-instr-info=C2=A0 -I /usr/src/contrib/llvm-project/llv= m/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=C2=A0 -d R= ISCVGenInstrInfo.inc.d -o RISCVGenInstrInfo.inc=C2=A0 /usr/src/contrib/llvm= -project/llvm/lib/Target/RISCV/RISCV.td
> llvm-tblgen -gen-emitter=C2=A0 -I /usr/src/contrib/llvm-project/llvm/i= nclude -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=C2=A0 -d RISC= VGenMCCodeEmitter.inc.d -o RISCVGenMCCodeEmitter.inc=C2=A0 /usr/src/contrib= /llvm-project/llvm/lib/Target/RISCV/RISCV.td
> llvm-tblgen -gen-pseudo-lowering=C2=A0 -I /usr/src/contrib/llvm-projec= t/llvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=C2=A0= -d RISCVGenMCPseudoLowering.inc.d -o RISCVGenMCPseudoLowering.inc=C2=A0 /u= sr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
> llvm-tblgen -gen-register-bank=C2=A0 -I /usr/src/contrib/llvm-project/= llvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=C2=A0 -= d RISCVGenRegisterBank.inc.d -o RISCVGenRegisterBank.inc=C2=A0 /usr/src/con= trib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
> llvm-tblgen -gen-register-info=C2=A0 -I /usr/src/contrib/llvm-project/= llvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=C2=A0 -= d RISCVGenRegisterInfo.inc.d -o RISCVGenRegisterInfo.inc=C2=A0 /usr/src/con= trib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
> llvm-tblgen -gen-searchable-tables=C2=A0 -I /usr/src/contrib/llvm-proj= ect/llvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=C2= =A0 -d RISCVGenSearchableTables.inc.d -o RISCVGenSearchableTables.inc=C2=A0= /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
> llvm-tblgen -gen-subtarget=C2=A0 -I /usr/src/contrib/llvm-project/llvm= /include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=C2=A0 -d RI= SCVGenSubtargetInfo.inc.d -o RISCVGenSubtargetInfo.inc=C2=A0 /usr/src/contr= ib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
> llvm-tblgen -gen-searchable-tables=C2=A0 -I /usr/src/contrib/llvm-proj= ect/llvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV=C2= =A0 -d RISCVGenSystemOperands.inc.d -o RISCVGenSystemOperands.inc=C2=A0 /us= r/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
>
> Any thoughts why this part is quite a challenge when it comes to memor= y usage? The other architectures do not possess such behavior... just curio= us.

Hi Mark,

S= orry for the late response, I got fully occupied at work for the past few d= ays due to deliverables. Thanks for your feedback and further inputs!
=
=C2=A0
I've not done any monitoring of buildworld buildkernel build
activity (RAM use, memory space use, swap partition use over
time) on RPi3B class hardware in a very long time.
It's alright, it so happened that I just observed that beha= vior on that particular part as it requires more memory than other architec= tures while compiling. The additional 3.5G swap partition really helps on t= hat part that's why I was so happy that the compilation continued and n= ever broke. Your input of having 3.5G swap allocation is very effective.

Even on systems that I have monitored in more recent times,
what I usually monitor tends to be builds with -jN (such as
-j4 fora 4-hardware-thread system). (I once did have an
example of -j3 taking less time than -j4 on a RPi4B.
<= br>
Wow, this is interesting this -jN. Let me explore this as wel= l. I usually build kernel the old way but recently since I have to include = building the world then I need to use the new way.
=C2=A0
Basically, the memory subsystem can be saturated without all
the cores being in use. The extra interference made things
take longer.)

Oh I see so it's the = reason.
=C2=A0
You had listed that you were using the likes of:

# cd /usr/src ; make KERNCONF=3DARM TARGET_ARCH=3Daarch64 \
buildkernel buildworld installkernel installworld distribution \
DESTDIR=3D/home/freebsd/rpi3b

I'll note that the standard order of the first 2 is:

buildworld buildkernel

This is because buildworld builds some software that
buildkernel does not build for itself but does use.
Okay this is noted, thanks for clarifying and correcting me, I= really appreciate it. I'll reflect on the proper build sequence for mu= ch efficiency.
=C2=A0
There is a kernel-toolchain target for avoiding the
need to do a full buildworld just to buildkernel , so:

kernel-toolchain buildkernel

is an expected sequence.

Okay I'll = take note of this too.
=C2=A0
I do not know how long a from-scratch buildworld
buildkernel without a -jN takes on a RPi3B these
days. If I remember right, for -jN with 1<N, I last
saw claims about such they were somewhere in the
range 36hr..48hr.

There's an ongoing bu= ild at the moment, it's already taking 41 hours since I started it. I t= ook another build when I came back home from the office.
=C2= =A0
But I'm = unsure of the specific N
that was in use. Nor do I know the storage media
type(s) involved, for example. I do not remember
any reports for -j1.

I'll try this = with RPi 3B. The current build that I have will be my baseline.
<= br>
Use of the likes of: vm.pageout_oom_seq=3D120
was essential to such -jN usage on a RPi3B as N
gets larger. Of course, swap partition use for
paging was also essential.

Wow, that= 9;s great! I have this=20 vm.pageout_oom_seq=3D120 configured in my system now based on your previous= inputs.

Likewise use of:

vm.swap_enabled=3D0
vm.swap_idle_enabled=3D0

can be important to not losing communication
with the RPi3B. Those last 2 are not tunable
but are writable:

# sysctl -aT | grep swap_
# sysctl -aW | grep swap_
vm.swap_enabled: 0
. . .
vm.swap_idle_enabled: 0
. . .

(This means that they have fewer places where
assignments can be made. For example, the
loader can not make the assignments.)

By contrast, vm.pageout_oom_seq is both
writable and tunable:

# sysctl -aW | grep oom
. . .
vm.pageout_oom_seq: 120
. . .

# sysctl -aT | grep oom
. . .
vm.pageout_oom_seq: 120
. . .

(So even the loader can make such assignments.)

Yes, I have these two sysctl parameters configured in the system. = Thanks for the details and further inputs.
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex"> I'll note that I've no interest in using arm hardware
to build for other types of hardware. So I normally
have the targeting of support for building for other
architectures disabled when I build on aarch64 or
armv7. (Basically, a less complete clang/clang++
related toolchain ends up being built.)

Ah okay, so you mean to say that you disable these other architectures by = declaring and accomplishing it in the /etc/src.conf?

I'll provide an update here once the build is done knowing how long = it takes to finish.

Thanks and best regards,
Archimedes
--00000000000025763905ecb5d31f--