From nobody Mon Aug 05 21:35:12 2024 X-Original-To: freebsd-arm@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 4Wd8qd6BdKz5Sl9m for ; Mon, 05 Aug 2024 21:35:25 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic313-20.consmr.mail.gq1.yahoo.com (sonic313-20.consmr.mail.gq1.yahoo.com [98.137.65.83]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Wd8qd3XdCz43Nk for ; Mon, 5 Aug 2024 21:35:25 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1722893723; bh=LWvEYb+5MHo+I+RZHBeVptKoNfrgP5JRIN7poffxYSM=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=T3kpHVhvkCwgKtGTTQWVrDCx4qQc5inJ9pjb4LJJfgkHLjETZUJww29BP1VLEucpm6Vfg2TC30NR1sV+90svZc5WNT1oiveupd+PSvPkuRfbmNtec1fRuokuwlEnP5WDoDyLE5S61xmGW+R0stc4aKjRRuIt3lhvb6TRgYV+HyRm8qEhjKtxMDaaCyBm+rhcdAeTgtbhgALiecJ78J/ogi2LnChzDInwa2p/RAr889OrsEuUvKyH3vQW2MCV5hiJ5bsK6utTnkSyu6WNoKIJnUCfQ0V5Y2WxqPz1QCp926zVhlKua9TBB32Zo5Z68nDxK5v2lkRMvw6qfE5CV1DPLg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1722893723; bh=LfHlseS58GF3yKiSt7W9f5vqY+tSwRoOkSo8jjTOuh3=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=U7fkvJmV0oHnHm0cmu8rCpQE89ceJ7ffsbHnzczRJmGwUFF/ipxNVDIykTtfodqfhFMD8KWDMzOLh8m9Y2ZuoHot2OOkYg09Ylz7mO/bSFk9QsW8BQ04+6TrL+Zk3jMdgZPOXDKF11sHN11tacHCCVSYmb0fxU+cBELz5xSlhCEuhiYLHW80uPc/Xji5Njk1jg8QQqC732Sy2z4lwVWxuvYglzpnaTXJBO491uQMlhYXsnVVlUd2pC+hoD/0B2OvsgJ5XpycOq62jflgp27zmFR6yKb5IFVdMKfX8KqAddpWGVx2SdF1Ev/lTEerTIGMCBDzfmB5Tw2QJ/wJ0H/jUg== X-YMail-OSG: O71Mk1QVM1n7_ZEB5qe1sUJ3q0.ugXIyThXgnw0SHGXO6yWpD7Pc4q43UOQeGcz F.kzdANCSsCzmPmFO1JVJYyeGyZAzzRrLa.bcEmQ4AVLsztlgGFOtMqk1mV6xq_aSyHRutkODbCS eEiVCtHTwASS7JGFTiYIdrCwh5eHYS93e_B9IhUDNXeJsepKWSPl6ItqZP80wzybWqyQvkhgxfVQ SZM6ZVxQh6BNtj_0HoDrSr_2p_UiMDb5V03Piyo0xqyfRdDhZloA3mXI85g07nsHRLT5PrUKpvDm QqOhbNX85bs6AKdLTv4exymsrjRaK63r71I2kq8v5HKtnzTyvzqLcfDwV12xm6SnyVAIzluX5mBv MGEV03x9OUPJMsJbu.q8dfU9oP5NfoMXnG0ePVDj8pW6zSIokjjORpYh_cvx8LAnel4EEwpF5bLz PvAcLV9NcD5QtRQpHscHpkVvdzmgI_KsOMpt0lkByUIFWe_ynMj._5n_X5s_P80_8N7NBGUeYAi7 Pilx_x9BmYlsqzfXET7X6b9_OfXSfA_nXbTuyaUFBjZLwge00vKXbvcjqMkmz68Nx.rDIHoPkh6N 33IumIThU2gsk.896yBssYD_zOYEc8ZaitfiUfp204wfLQSDwlQJxCOWg8pX6PzVua2KLo07yjlL 1q_.sPE.4xG9S_x4DltD.M8nf0nUtswUYc2MX46BY9q5rWnQPlNNxX4BZfo6U_KdX8iD4.l7kV2n ZUo_ZmpSfmBna4.2ggq66vIAjkawxXcdAZMsXbsaS9aGN6Xmdc65t_SBt8GCrq4Xy5CbdDt72Fso 6fzfFu9jbL4LeV45L7GMeMgCC1ziroQqR99dnoi_oxgcBPPOyavHRJ_qxsN5I4U0LKs.R3ctbbSR s8hVtGRSSTGDmFc7UqcQbVt69vWjchxt8DUKpr0uo_8a_JMoyGlz.D1sfy4eBDWHkCKN4yr3KO0H 0EdFVu6Ldvz9JYHxztkuH8SvDxiyOEIHkVGKBs2Wi_mkl.RxSaxHU1D5Naj7zLvfGJpEcwR3QCh7 4bMRn4iAjBkxEa2WytDPE.wi5kfS4cwSuwdtkWr1.RCPNFypoYHuiQMQivMQ7uCi0grm7Z_xSizT f_UlSvYO5fTc.MYo6d353SsCCvtie5Bqa0EyAhUkv6pV1eOOgpERqPYONSIbD9JTua06YvZILH1B UVgnb1HbvyP8w_7e3vsEBdcr0QC97DwIWmwzaDJCXKg68omqYQKscNKgcW_7itl6hGSqeauH0LsA mw9qJzL7o5tdoRJq2fY2IjMmgFgbaDOd.Gg3K8Ujnn6Kln69pfKJHZVVZ5keC5ZCPb3xrkbI9cNL 3q7RpshsYaVJCJxKLY4WX5jaiHDObq9Pm1Xueerrosyi52HKHYKyK_kdiaAOci_gvp0DHKhnXiHG A8yXkPw6pXLl522XTbnYdEgVIUke8EQYShV2qxlW7vEhCxdua3SFF3Vo3b1KrftYDbAFgn6D_Xyi k7mso1TAZHLHvQ42IGFLJhtFUjk3RZGLXV9Hvuru_a9GfYTC1LDLQ2iMtFeDRUoIWvkfV9EHRhME r8U_iTKnJDdsMByN91ybFZmJUJIA6SH7_5RRTBGwef6RjOGj7ZBhItiSkl6tEups0xkRMG_p9Yl3 CwT_AdTH8inMUX6fEQO95nZVTJdBwXmhLARUNQFP6E58qJDHyuYlZU0hbNdPvUUP0BWx.WvgYM.K nypkzPJPgTJW5UOtm.vjG4YFmmm0W8lQih7hfeDvS7KndRJWQ.SxcsBj9nz6b5Vp7iW_1QKxWwPA fTXW3WUzciapjpXvUzCkmT.baCUo53RcUBcDrIoKI_YSMSFVfFPfHK.D9CxwI17qDTMDwjieYXHt OSx0iAeL6daQ825CGfPBfWx3bDTclSPwkUFIfxr._Ga0aBUQDn02R0KxcAAo6s1P5dedINgTcgt0 4HYNwhpQXCwYT9mlSce3cxCmXrpNteJ9KFZCYrENDIDB1KrzC0Qq817uKNf9KLiB0mbEVINbA.yx YvF4r.ZAPtiK.Wc2Lhes9mfZteEDALZicl0o19IlLhNU.j2KeT2BJDhf2HPuScJYCH.thuWTqz8o e6zNhto7CmjsuV0JAlwU6ga85i19Uxz5V3HebFVy1jlK8mD1KYVckKprOC1rvyDDsKDLyWoMocWF U4wtDq8xR3jeqgD._jGQcNMxZTjwk.vAfF6e6.y.YJou2nNjjPlBzdCQX5DldmeW2Xch_vPzcTZr F8VUTd8FpxoEd.2o4FH_FztA4q1PukZ4AckTOWPTisL2H2iISP5au_h.NzRmBbnYuyl8aiTqvAdJ ncABVNAX6xABbknrH3T.DJI0_JvubMzjUCESAo1HjLNj. X-Sonic-MF: X-Sonic-ID: ad507096-afb7-4400-b266-9ddd2c5f7428 Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Mon, 5 Aug 2024 21:35:23 +0000 Received: by hermes--production-gq1-5d95dc458-kk28l (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 613fd945f2f80815bc67accffec30e46; Mon, 05 Aug 2024 21:35:23 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\)) Subject: Re: Any known way to build devel/llvm* ( such as devel/llvm19 ) with --threads=1 for its linker activity during the build? From: Mark Millard In-Reply-To: <4b5a6fa1-3b08-4b8b-8577-c548116d2115@freebsd.org> Date: Mon, 5 Aug 2024 14:35:12 -0700 Cc: FreeBSD Toolchain , FreeBSD ARM List Content-Transfer-Encoding: quoted-printable Message-Id: References: <4FFD603F-E67C-4B62-B91B-8BE365EAA050@yahoo.com> <82E78798-C376-45C4-80FE-96AD14229419@yahoo.com> <0b3b532c-ae94-439c-81aa-9e80a08af43f@freebsd.org> <4b5a6fa1-3b08-4b8b-8577-c548116d2115@freebsd.org> To: mmel@freebsd.org X-Mailer: Apple Mail (2.3774.600.62) X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Queue-Id: 4Wd8qd3XdCz43Nk On Aug 5, 2024, at 08:57, meloun.michal@gmail.com wrote: > On 05.08.2024 11:09, Mark Millard wrote: >> On Aug 5, 2024, at 00:44, meloun.michal@gmail.com 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. >=20 > 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). >=20 > 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=3Dno 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+=3D -DLLVM_ENABLE_TERMINFO=3DOFF CMAKE_ARGS+=3D -DLLVM_VERSION_SUFFIX=3D OPTIONS_DEFINE=3D BE_AMDGPU BE_WASM CLANG COMPILER_RT DOCS LLD = STATIC_LIBS -OPTIONS_DEFAULT=3D BE_AMDGPU BE_WASM CLANG LLD +OPTIONS_DEFAULT=3D BE_WASM CLANG LLD OPTIONS_SINGLE=3D BACKENDS OPTIONS_SINGLE_BACKENDS=3DBE_FREEBSD BE_NATIVE BE_STANDARD OPTIONS_EXCLUDE_armv6=3D COMPILER_RT @@ -103,7 +103,7 @@ OPTIONS_DEFINE_powerpc=3D GOLD OPTIONS_DEFINE_powerpc64=3D GOLD OPTIONS_DEFINE_powerpc64le=3D GOLD -OPTIONS_DEFAULT+=3D BE_STANDARD COMPILER_RT EXTRAS LIT LLDB MLIR = OPENMP \ +OPTIONS_DEFAULT+=3D BE_NATIVE COMPILER_RT EXTRAS LIT LLDB OPENMP \ PYCLANG POLLY STATIC_LIBS OPTIONS_DEFAULT_amd64=3D GOLD OPTIONS_DEFAULT_powerpc=3D GOLD @@ -211,8 +211,8 @@ CONFLICTS_INSTALL=3D ${PORTNAME}${LLVM_SUFFIX} = ${PORTNAME}${LLVM_SUFFIX}-lite .if defined(WITH_DEBUG) CMAKE_BUILD_TYPE=3D RelWithDebInfo -STRIP=3D .endif +STRIP=3D PLIST_SUB+=3D LLVM_MAJOR_MINOR=3D${LLVM_MAJOR_MINOR} \ LLVM_MAJOR=3D${LLVM_MAJOR} \ @@ -224,10 +224,10 @@ FIRST_COMMAND=3D = ${COMMANDS:C/^/XXXX/1:MXXXX*:C/^XXXX//} MAN1SRCS+=3D ${LLVM_MAN1SRCS} -STRIP_LIBS=3D BugpointPasses.so \ - LLVMHello.so \ - ${LIBNAME}.0 \ - libLTO.so +#STRIP_LIBS=3D BugpointPasses.so \ +# LLVMHello.so \ +# ${LIBNAME}.0 \ +# libLTO.so EXTRAS_LIBS=3D \ libclangApplyReplacements \ Note: This amd64 testing is not using --threads=3D1 for linking. A Hyper-V context for amd64-as-amd64 set up for small memory testing = with 4 Hyper-V cores: real memory =3D 2147483648 (2048 MB) avail memory =3D 2029309952 (1935 MB) Swap: 3584Mi Total So: AVAIL_RAM+SWAP =3D=3D 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.) =46rom 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 =3D=3D 0.75 GiByte[RAM+SWAP]/Core, well under 2 = GiByte[RAM+SWAP]/Core. =46rom 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 Commit: Bjoern A. Zeeb 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 Commit: Jan Beich 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. =3D=3D=3D Mark Millard marklmi at yahoo.com