On Aug 5, 2024, at 08:57, [email protected] wrote:
> On 05.08.2024 11:09, Mark Millard wrote:
>> On Aug 5, 2024, at 00:44, [email protected] wrote:
>>>> . . .
>>> Tegra has 4 Cortex-A15 cores and 2 GB of RAM.
>> OrangePi+ 2ed: Cortex-A7 with 4 cores and 2 GiBytes of RAM.
>> I wonder if the 2483 MiBytes would end up being about the
>> same on the Tegra variation indicated.
>
> Yep, it must be +/-same. The 2/2 GB for userland/kernel is defined by HW.
> Only size of shared libraries may affect (lower) usable user space for given
> program.
>>> All ports are built with default options. The only non-standard item is the
>>> swap size -> I have 16GB of swap on a swap partition on the SSD.
>> Wow, 16 GiBYtes of swap space for 2 GiBytes of RAM. I guess
>> when the swap is added that you get a notice-pair of the
>> structure:
>> QUOTE
>> warning: total configured swap (. . . pages) exceeds maximum recommended
>> amount (. . . pages).
>> warning: increase kern.maxswzone or reduce amount of swap.
>> END QUOTE
>> with a rather large difference between the two ". . ." figures.
>> Do you make other adjustments to deal with the otherwise-reported
>> potential mistuning? It appears to make tradeoffs in the kernel
>> internal memory handling, if I understand right.
> The above message should be interpreted as: warning, the kernel may in word,
> rear case need to allocate additional
> memory when swapping some object(memory) out. This may leads to
> deadlock/panic. But again, event is this warning valid,
> resulting deadlock/panic is very rare. I newer see it in past many years...
Interesting.
>>> But I guess that's not important in this case.
>> At least for my context, it appears that memory allocations
>> are failing to find a big enough free area inside the
>> process's address space --without running out of system
>> RAM+SWAP space overall.
>> For the OrangePi+ 2ed ( and devel/llvm18 18.1.7 ) it was
>> during the earlier linker run for:
>> FAILED: bin/lli-child-target
>> . . .
>> LLVM ERROR: out of memory
>> Allocation failed
>> That much finished just fine on the Windows DevKit
>> 2023 used via a armv7 jail ( devel/llvm18 18.1.8_1 ).
>> The failure point was in a later link ( matching what
>> I saw via devel/llvm19 ).
>>> I just started build of llvm19 - but it takes few hours to complete..
>> Probably fewer hours than on the OrangePi+ 2ed but
>> more than on the Windows DevKit 2023 (if they were
>> completing, anyway).
>
> The native build is still running (60% in fact), arm32 jail build has been
> stopped on my Honeycomb (killed by OOM).Unfortunately this is an old problem
> and is common on all platforms. The current LLVM cannot be built without
> additional tricks on machines that have less than 2GB (RAM + swap) per
> core.....
FYI: A small RAM+SWAP test for amd64-as-amd64 for devel/llvm18 18.1.7 . . .
USE_TMPFS=no
Targetting BE_NATIVE without BE_AMDGPU and without MLIR. Avoiding being
stripped.
(MLIR is resource and time expensive to build but I make no use of it.)
(I also make no use of BE_AMDGPU materials.)
(I've not been doing any cross builds in a very long time.)
(Not stripping can make for better failure reporting.)
(Leading whitespace might notn b e preserved in the copy of the diff:)
# git -C /usr/ports/ diff devel/llvm18
diff --git a/devel/llvm18/Makefile b/devel/llvm18/Makefile
index 1b1f759ba50e..779ddf3bea7e 100644
--- a/devel/llvm18/Makefile
+++ b/devel/llvm18/Makefile
@@ -87,7 +87,7 @@ CMAKE_ARGS+= -DLLVM_ENABLE_TERMINFO=OFF
CMAKE_ARGS+= -DLLVM_VERSION_SUFFIX=
OPTIONS_DEFINE= BE_AMDGPU BE_WASM CLANG COMPILER_RT DOCS LLD
STATIC_LIBS
-OPTIONS_DEFAULT= BE_AMDGPU BE_WASM CLANG LLD
+OPTIONS_DEFAULT= BE_WASM CLANG LLD
OPTIONS_SINGLE= BACKENDS
OPTIONS_SINGLE_BACKENDS=BE_FREEBSD BE_NATIVE BE_STANDARD
OPTIONS_EXCLUDE_armv6= COMPILER_RT
@@ -103,7 +103,7 @@ OPTIONS_DEFINE_powerpc= GOLD
OPTIONS_DEFINE_powerpc64= GOLD
OPTIONS_DEFINE_powerpc64le= GOLD
-OPTIONS_DEFAULT+= BE_STANDARD COMPILER_RT EXTRAS LIT LLDB MLIR OPENMP \
+OPTIONS_DEFAULT+= BE_NATIVE COMPILER_RT EXTRAS LIT LLDB OPENMP \
PYCLANG POLLY STATIC_LIBS
OPTIONS_DEFAULT_amd64= GOLD
OPTIONS_DEFAULT_powerpc= GOLD
@@ -211,8 +211,8 @@ CONFLICTS_INSTALL= ${PORTNAME}${LLVM_SUFFIX}
${PORTNAME}${LLVM_SUFFIX}-lite
.if defined(WITH_DEBUG)
CMAKE_BUILD_TYPE= RelWithDebInfo
-STRIP=
.endif
+STRIP=
PLIST_SUB+= LLVM_MAJOR_MINOR=${LLVM_MAJOR_MINOR} \
LLVM_MAJOR=${LLVM_MAJOR} \
@@ -224,10 +224,10 @@ FIRST_COMMAND= ${COMMANDS:C/^/XXXX/1:MXXXX*:C/^XXXX//}
MAN1SRCS+= ${LLVM_MAN1SRCS}
-STRIP_LIBS= BugpointPasses.so \
- LLVMHello.so \
- ${LIBNAME}.0 \
- libLTO.so
+#STRIP_LIBS= BugpointPasses.so \
+# LLVMHello.so \
+# ${LIBNAME}.0 \
+# libLTO.so
EXTRAS_LIBS= \
libclangApplyReplacements \
Note: This amd64 testing is not using --threads=1 for linking.
A Hyper-V context for amd64-as-amd64 set up for small memory testing with 4
Hyper-V cores:
real memory = 2147483648 (2048 MB)
avail memory = 2029309952 (1935 MB)
Swap: 3584Mi Total
So: AVAIL_RAM+SWAP == 5519 MiBytes
Building just llvm18-18.1.7 :
[00:00:22] [01] [00:00:00] Building devel/llvm18@default | llvm18-18.1.7
[00:55:27] [01] [00:55:05] Finished devel/llvm18@default | llvm18-18.1.7:
Success ending TMPFS: 0.00 GiB
(My poudriere-devel is patched to report the ending TMPFS figures.)
From my patched-up top's output from monitoring during the build:
Mem: . . . , 1462Mi MaxObsActive, 582432Ki MaxObsWired, 1940Mi
MaxObs(Act+Wir+Lndry)
Swap: 3584Mi Total , . . . , 1090Mi MaxObsUsed, 2455Mi
MaxObs(Act+Lndry+SwapUsed), 2995Mi MaxObs(A+Wir+L+SU),
2996Mi (A+W+L+SU+InAct)
So, slightly under 3 GiBytes RAM+SWAP observed as used, well under 8 GiBytes.
3GiByte[RAM+SWAP]/4Core == 0.75 GiByte[RAM+SWAP]/Core, well under 2
GiByte[RAM+SWAP]/Core.
From this and the like of your OOM reporting, I get an idea how much MLIR,
BE_AMDGPU, and BE_STANDARD contribute to the RAM+SWAP use. (I've not tested
such directly in a long time.)
For reference:
# uname -apKU
FreeBSD 7950X3D-UFS 15.0-CURRENT FreeBSD 15.0-CURRENT #144
main-n271413-1f7df7570174-dirty: Sat Jul 27 16:01:52 UTC 2024
root@7950X3D-ZFS:/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERIC-NODBG
amd64 amd64 1500021 1500021
# ~/fbsd-based-on-what-commit.sh -C /usr/main-src
1f7df7570174 (HEAD -> main, freebsd/main, freebsd/HEAD) LinuxKPI: move
__kmalloc from slab.h to slab.c
Author: Bjoern A. Zeeb <[email protected]>
Commit: Bjoern A. Zeeb <[email protected]>
CommitDate: 2024-07-26 11:51:04 +0000
branch: main
merge-base: 1f7df757017404011732196e65981d9325f7a89f
merge-base: CommitDate: 2024-07-26 11:51:04 +0000
n271413 (--first-parent --count for merge-base)
# ~/fbsd-based-on-what-commit.sh -C /usr/ports
4e0616a2066d (HEAD -> main, freebsd/main, freebsd/HEAD) graphics/libavif: drop
maintainership
Author: Jan Beich <[email protected]>
Commit: Jan Beich <[email protected]>
CommitDate: 2024-07-13 01:31:18 +0000
branch: main
merge-base: 4e0616a2066dc9e45cef47de812efdea4e09709c
merge-base: CommitDate: 2024-07-13 01:31:18 +0000
n671165 (--first-parent --count for merge-base)
Note: This /usr/ports/ is from before devel/llvm19 or /devel/freebsd-gcc14 .
I've not synchronized this UFS environment with my experimention with a more
recent ports vintage. devel/llvm18 is at 18.1.7 still here.
Hyper-V is actually using the same UFS boot media as the native UFS FreeBSD
boot does --but is using a smaller swap partition.
===
Mark Millard
marklmi at yahoo.com
