From nobody Wed Nov 2 21:09:24 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 4N2ff96fBwz4gwRH for ; Wed, 2 Nov 2022 21:09:37 +0000 (UTC) (envelope-from archimedes.gaviola@gmail.com) Received: from mail-yb1-xb2c.google.com (mail-yb1-xb2c.google.com [IPv6:2607:f8b0:4864:20::b2c]) (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 4N2ff8737Mz4N1t for ; Wed, 2 Nov 2022 21:09:36 +0000 (UTC) (envelope-from archimedes.gaviola@gmail.com) Received: by mail-yb1-xb2c.google.com with SMTP id g127so52984ybg.8 for ; Wed, 02 Nov 2022 14:09:36 -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=msDjbYujCdnuqZ+5BiUlTNV+7pLbTdnxvUVlHTCtHPI=; b=K44MIcecsYdb+QlIeAeeWbost8kzI4uVxFhM6L63YBwKaVkG6ZuUBkeKc3NMHskqK/ SW6o5ZZdCtLQRT2Y20c8dEMxOfJflU9Y/jJ2hvD2NdsGcQPt939hOQ3eHjlW1lUXeT5f N9ftvYG/KR1K1gSOcct+4G45LKGRcjjcEi0z4yjBZXGBJj4GSDDZZm1JYXRU6b2YtuMR zeLXcYcAkZRi2Ozd7YnglaFbCS5E5xV2VBPQie5ka+BR7tQXQbrYdLIGEDGwtUHasBMy vR4XXbKFu6n7N395pdT+BYc8XwjRWeLSAzTg86vuYgZnJzgU3GIdZGp82Esfz7jvW3/W XiAg== 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=msDjbYujCdnuqZ+5BiUlTNV+7pLbTdnxvUVlHTCtHPI=; b=549i7BnUOhjCl3KKFdWCbUkgwOjaHZ4uV1msLUA5AKmtUu8hBk7n8E5Tej++5T7QNM YM2KMQGX2RLaii32h0qckIf2E8O2at5TZ9ZC3Flyr5aUrHn0gxjf7BmXZUCsojY+o3pW 9Eif1ByMD0L400N0kWKkixCgcKqHqz/oSoc5kWYIOScD0D0TxS6j1+AHPpI5r9SofO5u iM6y3o/h2QeRrARZGhDksv8b0et34eVQpzEEPi5EwJ4muf4M8Z6iz2n2kWs2bZtHN6T/ hhW9PsC32dLkG60qgzUFI7Zm09GYFvwRURRY+bhOWldUBFmZiQve/kPZ0AO69+j0HVgv mQzQ== X-Gm-Message-State: ACrzQf23GOOtqh7MJfDnfW84Sv8x954MKphftWDNocZDH7XDI78VOdz3 x1y7nIgTpncqo1rsYKCFa9VPfd3S4UORznmggVk= X-Google-Smtp-Source: AMsMyM4koggBLtVKWXiLuUKa3SaNXDyqEhYF0NjyBnlpfZg9Nac9ohdIVX3H4VIc9FA9VdtqwL8EzZGIsZXcOjUuPNc= X-Received: by 2002:a25:d216:0:b0:6cf:e9f4:ace2 with SMTP id j22-20020a25d216000000b006cfe9f4ace2mr5295371ybg.84.1667423375588; Wed, 02 Nov 2022 14:09:35 -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: Thu, 3 Nov 2022 05:09:24 +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="000000000000fe329b05ec834162" X-Rspamd-Queue-Id: 4N2ff8737Mz4N1t X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=K44MIcec; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of archimedes.gaviola@gmail.com designates 2607:f8b0:4864:20::b2c as permitted sender) smtp.mailfrom=archimedes.gaviola@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::b2c:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; DKIM_TRACE(0.00)[gmail.com:+]; TO_DN_ALL(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_TO(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --000000000000fe329b05ec834162 Content-Type: text/plain; charset="UTF-8" On Mon, Oct 31, 2022 at 1:47 PM Archimedes Gaviola < archimedes.gaviola@gmail.com> wrote: > > > Okay noted on GPT not MBR method with gpart. > > >> I did not happen to have a MBR example around. So I could >> only show GPT. The note was more to avoid confusion than >> anything, since the two are not equivalent for how they >> work. >> > > Okay, this is noted. > > >> >> > By the way, what's the proper allocation size of swap in FreeBSD? >> >> FreeBSD has a waring that it produces indicating possible mistuning >> when you potentially have too much. An example is: >> >> warning: total configured swap (2097152 pages) exceeds maximum >> recommended amount (916632 pages). >> warning: increase kern.maxswzone or reduce amount of swap. >> >> The numbers are dependent on the amount of RAM present and >> other details. >> >> My understanding is that increasing kern.maxswzone has tradeoffs. >> I avoid getting the message because I do not understand the >> tradeoffs or how to manage the tradeoffs or even how to identify >> an instance of hitting such a tradeoff. >> > > Basically the warning messages you've shared are the messages I > encountered with my older FreeBSD system running on MIPS32 at the time I > allocated a swap partition because of the higher allocation size I've made. > So what I did is gradually adjust the swap size until such warnings > disappear. I did not go through the details as most likely it requires a > deeper knowledge on this area. That's why this experience illuminated me > again with my RPi 3B ARM system on the proper allocation size. But yes, > below you have the allocation size. > > >> >> For aarch64 I've been about to have swap of about 3.4 to 3.5 or >> so times the amount of RAM without getting the warnings. That >> is why 3.5G in my RPi3B example. (So RAM+SWAP approx.= 4.5*RAM.) >> (armv7 only allows more like 1.8 times the RAM before getting >> the warning.) >> > > Okay this is noted. I'll take the 3.5G size as this is based on your > actual experience. > > >> >> I avoid even getting too close to the warning as there seems to >> be some build-to-build variability in what fits vs. not. This >> avoids having to frequently adjust the size. >> >> > I, too, need to avoid such warnings as much as possible with this RPi 3B > configuration. > > >> Going from the other side, how much RAM+SWAP will your activities >> use? To avoid accurately figuring out such, you may just want to >> have near the 3.4 to 3.5 times RAM. (There have been times when >> clang had memory use oddities that required more than normal for >> a time, for example.) >> > > I'll just follow the size you have and let me observe how it goes. > > >> >> > This RPi 3B has 1GB of RAM (~947 MB), do I need to set twice the >> capacity of this physical RAM? >> >> Ultimately your choice. How much parallel activity you >> want to attempt likely contributes. If you build ports, >> you might do so in a way that uses more RAM+SWAP than >> system builds do, for example. >> > > Okay this is noted. For now, building the kernel and world is my goal, no > ports yet. > > >> >> > (Note: swap file usage is subject to deadlock conditions >> > avoided by use of swap partitions.) >> > >> > This is noted. >> > >> > >> > I use a serial console & ssh session only context to avoid >> > having sizable competition for RAM. >> > >> > I avoid using tmpfs because it competes for RAM use. >> > >> > I use the likes of ( in, say, /boot/loader/conf ): >> > >> > # >> > # Delay when persistent low free RAM leads to >> > # Out Of Memory killing of processes: >> > vm.pageout_oom_seq=120 >> > >> > This delays potential "killed: failed to reclaim memory" kills, >> > possibly long enough to reach a state where sufficient memory is >> > reclaimed. >> > >> > Alright this is well noted too. >> >> There is tuning related to "a thread waited too long to >> allocate a page" that happens because of paging I/O >> characteristics. But but I've not hit that type of >> error. >> >> I'll also note that the "out of swap space" case is a >> misnomer in that it is one or two of 2 internal data >> structures that is out of space, not necessarily the >> swap space on the media. Again, I've not ever hit that >> type of error. I'm not aware of tuning for this case. >> > > Okay, noted as well on this info. Let me just try the 3.5G swap > allocation. I will post another thread if I ever encounter these types of > errors. > > >> >> > I'll note that the status "killed: failed to reclaim memory" does >> > not require that swap be used much at all. Sustained low free RAM >> > from just one process that always stays runnable and has a >> > sufficiently large active set of pages can be sufficient to end up >> > with such kills. Having swap allows for inactive pages to get out >> > of the way, which can help. >> > >> > I use the likes of ( in, say, /etc/ssyctl.conf ): >> > >> > # >> > # Together this pair avoids swapping out the process kernel stacks. >> > # This avoids processes for interacting with the system from being >> > # hung-up. >> > vm.swap_enabled=0 >> > vm.swap_idle_enabled=0 >> > >> > This allows paging to the swap space but disallows moving >> > kernel thread stacks to the swap space. Otherwise the >> > processes used to interact with the RPi3 can become >> > non-runnable, preventing such interactions. >> > >> > Okay this too is well noted. >> > >> > >> > I have NVMe or SSD based USB media, not microsd cards nor >> > spinning rust. (I use just bootcode.bin and timeout files >> > on microsd media for the RPi3B. Even the rest of the RPi* >> > firmware is on the USB media, as well as u-boot.bin .) >> >> This may contribute to why I've never gotten a "a thread >> waited too long to allocate a page" on any system. (Some >> systems, while bootable via USB3 media I have, also have >> have even faster internal media that is normally used.) >> > > Alright so there's significance. > > >> >> > My usage of such a configuration struture for building >> > software (world, kernel, ports) applies to all the >> > systems I do such with, including ones with a lot more >> > resources, including a lot more RAM. >> > >> > Thanks for these inputs, noted on these things! I haven't tried NVMe >> and SSD media in my RPi 3B. So, they are far more superior as compared to >> microSD cards when it comes to building software? >> >> My understanding is that microsd card media is fairly >> generally not as good for such contexts: slower, fails >> sooner, etc. >> > > I'll take note of this one as I may encounter those attributes along the > course of building software. It's something that I need to explore and do > some research ahead. > > >> >> I happen to boot multiple types of machines from the >> same media so I use USB3 media that is compatible with >> USB2 use, a single such USB3 device not needing a >> powered hub for use on the likes of an RPi3B. (Lots >> of USB3 media around would require external power for >> USB2 or an RPi3B use.) I need a powered hub for 2 or >> more such media on a RPi3B. >> > > Okay, that's right. In my experience, inserting some devices tends to > reset the 4 USB ports' power, thus to prevent such behavior needs a > self-powered hub. > > 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. Thanks and best regards, Archimedes --000000000000fe329b05ec834162 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Oct 31, 2022 at 1:47 PM Archi= medes Gaviola <archimede= s.gaviola@gmail.com> wrote:

> Ok= ay noted on GPT not MBR method with gpart.


I did not happen to have a MBR example around. So I could
only show GPT. The note was more to avoid confusion than
anything, since the two are not equivalent for how they
work.

Okay, this is noted.
= =C2=A0

> By the way, what's the proper allocation size of swap in FreeBSD?<= br>
FreeBSD has a waring that it produces indicating possible mistuning
when you potentially have too much. An example is:

warning: total configured swap (2097152 pages) exceeds maximum recommended = amount (916632 pages).
warning: increase kern.maxswzone or reduce amount of swap.

The numbers are dependent on the amount of RAM present and
other details.

My understanding is that increasing kern.maxswzone has tradeoffs.
I avoid getting the message because I do not understand the
tradeoffs or how to manage the tradeoffs or even how to identify
an instance of hitting such a tradeoff.

Basically the warning messages you've shared are the messages I encoun= tered with my older FreeBSD system running on MIPS32 at the time I allocate= d a swap partition because of the higher allocation size I've made. So = what I did is gradually adjust the swap size until such warnings disappear.= I did not go through the details as most likely it requires a deeper knowl= edge on this area. That's why this experience illuminated me again with= my RPi 3B ARM system on the proper allocation size. But yes, below you hav= e the allocation size.
=C2=A0

For aarch64 I've been about to have swap of about 3.4 to 3.5 or
so times the amount of RAM without getting the warnings. That
is why 3.5G in my RPi3B example. (So RAM+SWAP approx.=3D 4.5*RAM.)
(armv7 only allows more like 1.8 times the RAM before getting
the warning.)

Okay this is noted. I'= ;ll take the 3.5G size as this is based on your actual experience.
=C2=A0

I avoid even getting too close to the warning as there seems to
be some build-to-build variability in what fits vs. not. This
avoids having to frequently adjust the size.


I, too, need to avoid such warnings as= much as possible with this RPi 3B configuration.
=C2=A0
Going from the other side, how much RAM+SWAP will your activities
use? To avoid accurately figuring out such, you may just want to
have near the 3.4 to 3.5 times RAM. (There have been times when
clang had memory use oddities that required more than normal for
a time, for example.)

I'll just fol= low the size you have and let me observe how it goes.
=C2=A0
<= /div>

> This RPi 3B has 1GB of RAM (~947 MB), do I need to set twice the capac= ity of this physical RAM?

Ultimately your choice. How much parallel activity you
want to attempt likely contributes. If you build ports,
you might do so in a way that uses more RAM+SWAP than
system builds do, for example.

Okay thi= s is noted. For now, building the kernel and world is my goal, no ports yet= .
=C2=A0=C2=A0

> (Note: swap file usage is subject to deadlock conditions
> avoided by use of swap partitions.)
>
> This is noted.
>=C2=A0
>
> I use a serial console & ssh session only context to avoid
> having sizable competition for RAM.
>
> I avoid using tmpfs because it competes for RAM use.
>
> I use the likes of ( in, say, /boot/loader/conf ):
>
> #
> # Delay when persistent low free RAM leads to
> # Out Of Memory killing of processes:
> vm.pageout_oom_seq=3D120
>
> This delays potential "killed: failed to reclaim memory" kil= ls,
> possibly long enough to reach a state where sufficient memory is
> reclaimed.
>
> Alright this is well noted too.

There is tuning related to "a thread waited too long to
allocate a page" that happens because of paging I/O
characteristics. But but I've not hit that type of
error.

I'll also note that the "out of swap space" case is a
misnomer in that it is one or two of 2 internal data
structures that is out of space, not necessarily the
swap space on the media. Again, I've not ever hit that
type of error. I'm not aware of tuning for this case.
<= div>
Okay, noted as well on this info. Let me just try the 3.= 5G swap allocation. I will post another thread if I ever encounter these ty= pes of errors.
=C2=A0

> I'll note that the status "killed: failed to reclaim memory&q= uot; does
> not require that swap be used much at all. Sustained low free RAM
> from just one process that always stays runnable and has a
> sufficiently large active set of pages can be sufficient to end up
> with such kills. Having swap allows for inactive pages to get out
> of the way, which can help.
>
> I use the likes of ( in, say, /etc/ssyctl.conf ):
>
> #
> # Together this pair avoids swapping out the process kernel stacks. > # This avoids processes for interacting with the system from being
> # hung-up.
> vm.swap_enabled=3D0
> vm.swap_idle_enabled=3D0
>
> This allows paging to the swap space but disallows moving
> kernel thread stacks to the swap space. Otherwise the
> processes used to interact with the RPi3 can become
> non-runnable, preventing such interactions.
>
> Okay this too is well noted.
>=C2=A0
>
> I have NVMe or SSD based USB media, not microsd cards nor
> spinning rust. (I use just bootcode.bin and timeout files
> on microsd media for the RPi3B. Even the rest of the RPi*
> firmware is on the USB media, as well as u-boot.bin .)

This may contribute to why I've never gotten a "a thread
waited too long to allocate a page" on any system. (Some
systems, while bootable via USB3 media I have, also have
have even faster internal media that is normally used.)

Alright so there's significance.
=C2=A0
<= /div>

> My usage of such a configuration struture for building
> software (world, kernel, ports) applies to all the
> systems I do such with, including ones with a lot more
> resources, including a lot more RAM.
>
> Thanks for these inputs, noted on these things! I haven't tried NV= Me and SSD media in my RPi 3B. So, they are far more superior as compared t= o microSD cards when it comes to building software?

My understanding is that microsd card media is fairly
generally not as good for such contexts: slower, fails
sooner, etc.

I'll take note of this= one as I may encounter those attributes along the course of building softw= are. It's something that I need to explore and do some research ahead.<= br>
=C2=A0

I happen to boot multiple types of machines from the
same media so I use USB3 media that is compatible with
USB2 use, a single such USB3 device not needing a
powered hub for use on the likes of an RPi3B. (Lots
of USB3 media around would require external power for
USB2 or an RPi3B use.) I need a powered hub for 2 or
more such media on a RPi3B.

Okay, that's= right.=C2=A0 In my experience, inserting some devices tends to reset the 4= USB ports' power, thus to prevent such behavior needs a self-powered h= ub.


<= /div>
Hi Mark,

Just an update, as kernel and w= orld compilation is ongoing with my RPi3B system (with swap partition) is d= oing so far, so good. It already surpassed the tough part that breaks the c= ompilation process here.
...
<= div>
llvm-tblgen -gen-asm-matcher =C2=A0-I /usr/src/contrib/l= lvm-project/llvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/R= ISCV =C2=A0-d RISCVGenAsmMatcher.inc.d -o RISCVGenAsmMatcher.inc =C2=A0/usr= /src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
llvm-tblgen -ge= n-asm-writer =C2=A0-I /usr/src/contrib/llvm-project/llvm/include -I /usr/sr= c/contrib/llvm-project/llvm/lib/Target/RISCV =C2=A0-d RISCVGenAsmWriter.inc= .d -o RISCVGenAsmWriter.inc =C2=A0/usr/src/contrib/llvm-project/llvm/lib/Ta= rget/RISCV/RISCV.td
llvm-tblgen -gen-callingconv =C2=A0-I /usr/src/contr= ib/llvm-project/llvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Targ= et/RISCV =C2=A0-d RISCVGenCallingConv.inc.d -o RISCVGenCallingConv.inc =C2= =A0/usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
llvm-tbl= gen -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 RIS= CVGenCompressInstEmitter.inc.d -o RISCVGenCompressInstEmitter.inc =C2=A0/us= r/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
llvm-tblgen -g= en-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 RISCVGenDAGISel.inc.d = -o RISCVGenDAGISel.inc =C2=A0/usr/src/contrib/llvm-project/llvm/lib/Target/= RISCV/RISCV.td
llvm-tblgen -gen-disassembler =C2=A0-I /usr/src/contrib/l= lvm-project/llvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/R= ISCV =C2=A0-d RISCVGenDisassemblerTables.inc.d -o RISCVGenDisassemblerTable= s.inc =C2=A0/usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.tdllvm-tblgen -gen-global-isel =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= VGenGlobalISel.inc.d -o RISCVGenGlobalISel.inc =C2=A0/usr/src/contrib/llvm-= project/llvm/lib/Target/RISCV/RISCV.td
llvm-tblgen -gen-instr-info =C2= =A0-I /usr/src/contrib/llvm-project/llvm/include -I /usr/src/contrib/llvm-p= roject/llvm/lib/Target/RISCV =C2=A0-d RISCVGenInstrInfo.inc.d -o RISCVGenIn= strInfo.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= /include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV =C2=A0-d RI= SCVGenMCCodeEmitter.inc.d -o RISCVGenMCCodeEmitter.inc =C2=A0/usr/src/contr= ib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
llvm-tblgen -gen-pseudo-l= owering =C2=A0-I /usr/src/contrib/llvm-project/llvm/include -I /usr/src/con= trib/llvm-project/llvm/lib/Target/RISCV =C2=A0-d RISCVGenMCPseudoLowering.i= nc.d -o RISCVGenMCPseudoLowering.inc =C2=A0/usr/src/contrib/llvm-project/ll= vm/lib/Target/RISCV/RISCV.td
llvm-tblgen -gen-register-bank =C2=A0-I /us= r/src/contrib/llvm-project/llvm/include -I /usr/src/contrib/llvm-project/ll= vm/lib/Target/RISCV =C2=A0-d RISCVGenRegisterBank.inc.d -o RISCVGenRegister= Bank.inc =C2=A0/usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td=
llvm-tblgen -gen-register-info =C2=A0-I /usr/src/contrib/llvm-project/l= lvm/include -I /usr/src/contrib/llvm-project/llvm/lib/Target/RISCV =C2=A0-d= RISCVGenRegisterInfo.inc.d -o RISCVGenRegisterInfo.inc =C2=A0/usr/src/cont= rib/llvm-project/llvm/lib/Target/RISCV/RISCV.td
llvm-tblgen -gen-searcha= ble-tables =C2=A0-I /usr/src/contrib/llvm-project/llvm/include -I /usr/src/= contrib/llvm-project/llvm/lib/Target/RISCV =C2=A0-d RISCVGenSearchableTable= s.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/llv= m/lib/Target/RISCV =C2=A0-d RISCVGenSubtargetInfo.inc.d -o RISCVGenSubtarge= tInfo.inc =C2=A0/usr/src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.t= d
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/usr= /src/contrib/llvm-project/llvm/lib/Target/RISCV/RISCV.td

Any thoughts why this part is quite a challenge when it comes to mem= ory usage? The other architectures do not possess such behavior... just cur= ious.

Thanks and best regards,
Archimede= s

=C2=A0
--000000000000fe329b05ec834162--