Date: Sun, 19 Sep 2021 02:12:17 -0700 From: Mark Millard via freebsd-toolchain <freebsd-toolchain@freebsd.org> To: FreeBSD Toolchain <freebsd-toolchain@freebsd.org>, Free BSD <freebsd-arm@freebsd.org>, freebsd-ports@freebsd.org Subject: armv7 target (on aarch64 HW) and poudriere-based emulators/mame link failure vs. success based on the number of cores Message-ID: <64B80EEA-DECC-4286-AC80-5BE55B7F19D4@yahoo.com> References: <64B80EEA-DECC-4286-AC80-5BE55B7F19D4.ref@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400032 1400032 # cd /usr/ports/ # ~/fbsd-based-on-what-commit.sh=20 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. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?64B80EEA-DECC-4286-AC80-5BE55B7F19D4>