armv7 target (on aarch64 HW) and poudriere-based emulators/mame link failure vs. success based on the number of cores

On a HoneyComb (16 cores) I did a bulk -a targetting armv7 that had
emulators/mame fail as unable to allocate during a link. Linking
by default use slightly more threads than the freebsd cpu count.
The HoneyComb had 64 GiByte of RAM and over 120000 MiByte of
swap partitioning set up. The swap was never used during the
bulk -a examples.

On a MACCHIATObin Double Shot (4 cores) with nearly identical media
booted, attempting to build emulators/mame worked fine. (I did not
try a bulk -a: it would take far too long for my time preferences.)
(I've also gotten a report of success building on a RPi4B, also
4 cores.)

The HoneyComb failure looks to me like like hitting the process
size limitations for armv7, something that did not happen on the
MACCHIATObin Double Shot or RPi4B (fewer cores).

It looks to me like 32-bit architectures (such as armv7) should
possibly have the multi-threaded link disabled by default
for FreeBSD unless ports are adjusted to disable multi-threaded
individually.

(I do not claim that mame is the only example of such an issue in
the bulk -a --or on systems with even more cores. It just happens
to be an example that I noticed.)

For reference:

# uname -apKU
FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #12 main-n249019-0637070b5bca-dirty: Tue Aug 31 02:24:20 PDT 2021     root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-NODBG-CA72  arm64 aarch64 1400032 1400032

# cd /usr/ports/
# ~/fbsd-based-on-what-commit.sh 
branch: main
merge-base: b0c4eaac2a3aa9bc422c21b9d398e4dbfea18736
merge-base: CommitDate: 2021-09-07 21:55:24 +0000
b0c4eaac2a3a (HEAD -> main, freebsd/main, freebsd/HEAD) security/suricata: Add patch for upstream locking fix
n557269 (--first-parent --count for merge-base)

BUT: a rust 1.55 was in use on the HoneyComb as a test for another
issue, at least fore the second bulk -a run that then tried to
see what would no longer fail when targeting armv7.

(Note: The HoneyComb is busy doing a bulk -a targeting aarch64
now.)


Side notes . . .

I'll note that the HoneyComb can do a from-scratch bulk -a targeting
armv7 in less time than the official FreeBSD servers do (via amd64).
A specific exxample was a bulk -a completed in somewhat under 87.25
hours, building 26995 ports successfully. (Not that I configure and
operate in a configuration matching official FreeBSD serves. I allow
a huge load average: 16 builds with ALLOW_MAKE_JOBS defined and
have a large swap partitioning for a 64 GiByte machine (for in case
of an unfortunately combination of overlapping huge builds).

Mostly this is likely due to having the lang/gcc* (and such) build
via a full bootstrap on amd64 targeting armv7. The native-toochain
cross-build use does not help after the first part of such a build.

Note: I do not normally do bulk -a or build rust or build mame.
The activity is experimental and a test of the HoneyComb.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)