From nobody Mon Aug 05 07:27:13 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 4Wcp1G2Cv4z5SksR for ; Mon, 05 Aug 2024 07:27:30 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-25.consmr.mail.gq1.yahoo.com (sonic312-25.consmr.mail.gq1.yahoo.com [98.137.69.206]) (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 4Wcp1D38H7z4j0J for ; Mon, 5 Aug 2024 07:27:28 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=PKS8wTxS; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1722842846; bh=i/yC5+matq9+pBRM+jnU8Kstb6NyrWubDQupnHd77jg=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=PKS8wTxSnfp4csmo1RgZKDOUgpzhtMyQLZgozy6AdyuWiwxXM2UNCYe/9fcclgbuZTtNj3W56elpFc9OO9qJo/oGhZbaagRjICMnVMjdRYJk9wC0GZ+XJBRQQfXPHcjQ3fGLKon3BXrjvcdML8+sy788VKY+qwk2VoYYEesxr1N0/rn49gVojF4AKnRw9uU+PTsy/zTk+tS+ZDvy4jOL9AzHtFXLeV88fObelvlXvmKW2THP66cfgeqzll5V71gmjSqmo4RHlqdAW8Oj0ZaSUugmU0+vqL7dpTNRqUBh9Zgro1pDE/r07UGPt35OR/oMhSe2ZCMeN6DSJACjWbcpig== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1722842846; bh=fJwLtwKOISGybkNAu3gdW071r7NifmHG1SFTSbZCBfJ=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=gG1S+YxsTxBy61wM7z15LTI9waK++KHKIkp8ZTMhJ32LSTre3M8FRiVOl3tKglcK/a7CSEgd50QaZcCyr6QVMCP4DoAYRwwebwH4egzX9HtJQr4Ab0535s6/hkjl0FsBZKaYa3smXaXwC4Q0Wi71zZ3GgvaamRtrz7V1FRscezeCG9fGq5OPh2AaNsdXbvkeVlYphJheGJHtX4CWSiF+POPXCAsur01GYhdxP1JOLYQFmxBybIWUDByjalTfIrW2gV7Gpl4ZM7PAz5+HTbFR0l6izhA8/hgcu0SexdYc0123Zxil3+R8ScS31/LL9f4D+EMzWPq3X6QIutQugGDe+A== X-YMail-OSG: 2Oq1n.wVM1kFeg7LStpBzBYn3nCCSk0E_Oo5RmYHZH60dGHVI1Dgx9sqswkV7iy r.fCWXCjWc4Sk6RVErpOHNvqWWkNCf_MtHLf7Tdir2LZdd3AjYpeVRJfD8a6pdL9cPtVfkK0eKuv RYsB5E214Z4Eow9JzN8EWZO.eEieu14Jz5YZCwL3PicWv.sZtfodTiL.UM3qOhjEMijViYf72iMd G878w34mgkhKOJs66X.SfYDzh3IHT35y4xCqbi3N9nwzGxuHGfG5V3p5xJiEwk1Rkwr57Pq83u9Y rcRJhtT.INdl0GPvXmFQkcInAO1iUDp9ZsVv5t.EngxkjY3cvL.f.7aYSZPNDjt8axFmse0V08z6 9Pa0zfTVoNk0N_y8cFBCpQ3NtEfl_j7yX0TCjLfsVmlsMEOX1Fzjipx_X9yjcqIR_nIHjRz5U3Vq Dc1iFx6iGr49v5aq_2gVG3hxB5z49i61Rneaak_N.uYkOlfCS5vLHc_SKg6GTd0or.EaeWasz.rZ AW80hl6vFNVvDl18WCYvELWIvkUupcFaRxZkReLbybVlVJfLjqqwQHz6tei6h7xkr9tMLzlT9mWM V1iIdh1uryJ5WY_p4iyMob5RaKVxaEFH8a54B3gZ73eyD1VUB7Xw6uPulPXP196Yg.If_Moqw1CH 5cXMkx2m1XLuJocmJqdf8xTv1W.rbeYwx2C6dQm0wUk608Xtz43GVUrK2dGQLtRi7IcbXUSJ7wTo 1l_S.Qslc.zrpqb3u_TGxGDuPn_aUbpuuNP8wtlcgMPo1TpSbQBfueJtQR_mkaaSYKDigziloX_E 3pU5DPGwYkz.tXtugLPkYzOJ2BaO4GY4nZoWmqVxKpx0HxXQ4CQ.57W55.BYbMuy1dHpvQ9JhCMB x16EKJKl_fHDNvx0YcMnr61xinSZlMCh5fHpFlMYh7H7FU5.IdBxH4t92_.diO7JGE.Vu15j8zJx 6DeBP3sZj8QOiCO5CaIKkwQs1fTtT0Qg9y5dhypNBtuiZULEP5Mnem6vHwIFoOZVhopofUTEoGBe 3Oe9nDIZig6OwzHjjyc86uMceW5LlpRfMm_rPkA5OQwZ1ZwJ1U6iIwPPmN69TuefK9NwXtjcJwXM Igx6fyNJGFC8B9rw24KX4_1pc5EYv1a4R1fWtX.EzfsJD2WbZZgekSHQ06S98Xy6eNyxBuDLrPZQ 4rv24xaGqDqJF7o8iawqT4YJUk_I5qCLCvvCEZ7qA6D.B_ank5eKJet19A_Xsfv71vGYza_Shkzf YwKu_X1fLmet6ZL3_Jb_pfgnVgoFDoQAXVkIngOe3G3JWAL2l2pTnnf9E9TsemEzNda28NpVcLYv I65qH2bewlOjGshAEXSm_SlKjI0Js6RnVI_uVQ9mwV3o5ebWe06mZ4_xISuQBoUi_OpWOHqckyxS EeERGOMIxgPbYuPmLDsH_9Q1mlXk4krZ0Ptw_ibgEqafaJEehmbZCt_mgwZEbhVRrCKgt9nTOu5R XIeGrEcbNrDvY7Lga6zO4I35HC969frxuJz9H85xHPwDiMLsEuXx25SYyc8LJlFzIlsQRGdPPCqa g6zCRHZxVKSl8liLmREIoDG0w0IenI0To9WFztg_SYGVff9gz150UCYvKxjdqOpE30gv.Vp8Ewvj y1_c7_IVCB5cF2JqiOqTpNhPdUUDB7f.zP3i2ekk0uhEuD.1Tbn95uqvZR.dKUJYWeJZmsJrE76b .7jb6llKAdd_dsQSTVXv1M9dEOQ_dwCgzDbuTTqudWYIIYB8wx0pl0GoA80AviY.VbY3XfSzcJAs yQTlzBN3lINwB1SrJi2.ISdICronj4MweGN7jsPyYoc_QNkO2bK_rFz2lUVEpFyzy5LlmV7lEtKU QpIyJQ77zaJ93VWQ4K0excko8WLjgNidO8XpeliiIMaxBdntjCJx.DIQw.mDN9ezLXtXbx8DLqbd SlEPwPrz4gvl.ZIn.CDRu_ZUahyXb8uOKg11qSuWIzeg0Nq8aPyGwMx6.iH8U6iMBHRK9zNg_qQb U_NIrUTw_meEeb8BBsn2TOrXmSILhAZ3hRdF_oZ5S.j1yO6SrVEit0OrCStxICiKKA8Hx_ABBPIh O0rui01BnpNnGFtNHrj7HvaCUrhowyHJCyOySNrHFCkzAk2mb8Qy4Rbjw6fp4dg8YOsA8QFImi4C bsaLsqsBOQaNfiSdIMH8JeecgrafZCnfQsMk3XuFPi9vadGvH6EsyhAMLV9ivXjT6_t1edz_LW43 2RtmfhXEK9PRBU09OZreY7CMm4tj_il.DFbuRH8HkvGpOXCOmtzfeonuby6DHOxlGkEsXFeVupg- - X-Sonic-MF: X-Sonic-ID: 19a0e0d9-979a-49f4-b15e-c9369b5a855e Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Mon, 5 Aug 2024 07:27:26 +0000 Received: by hermes--production-gq1-5d95dc458-5n5gs (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID f2d0b87131e3dc2b32fcce2abd96eba1; Mon, 05 Aug 2024 07:27:24 +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: Date: Mon, 5 Aug 2024 00:27:13 -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> To: mmel@freebsd.org X-Mailer: Apple Mail (2.3774.600.62) X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.93 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.93)[-0.933]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_FROM(0.00)[yahoo.com]; RCPT_COUNT_THREE(0.00)[3]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; APPLE_MAILER_COMMON(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.206:from]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.206:from] X-Rspamd-Queue-Id: 4Wcp1D38H7z4j0J On Aug 5, 2024, at 00:15, Mark Millard wrote: > On Aug 4, 2024, at 22:53, Michal Meloun = wrote: >=20 >> On 04.08.2024 23:31, Mark Millard wrote: >>> On Aug 3, 2024, at 23:07, Mark Millard wrote: >>>> My recent attempts to build devel/llvm18 and devel/llvm19 in an = armv7 context (native or aarch64-as-armv7) have had /usr/bin/ld failures = that stop the build and report as: >>>>=20 >>>> LLVM ERROR: out of memory >>>> Allocation failed >>>>=20 >>>> (no system OOM activity or notices, so just a process = size/fragmentation issue, or so I would expect). >>>>=20 >>>> On native armv7 I also had rust 1.79.0 fail that way so --but = aarch64-as-armv7 built it okay. >>>>=20 >>>> I'm curious if --threads=3D1 use for the linker might allow the = devel/llvm* builds to complete at this point. Similarly for rust. (top = showed that the ld activity was multi-threaded.) >>>>=20 >>>> Note: The structure of the poudriere-devel based native build = attempts is historical and it used to work. Similarly for the = aarch64-as-armv7 based build attempts. For now I'd just be exploring = changes that might allow much of my historical overall structure to = still work. But I expect that things are just growing to the point = building is starting to be problematical with process address spaces = that are bounded by a limit somewhat under 4 GiBytes. >>>>=20 >>>>=20 >>>> Native armv7 was a 2 GiByte OrangePi+ 2ed (4 cores) that had >>>> at boot time: >>>>=20 >>>> AVAIL_RAM+SWAP =3D=3D 1958Mi+3685Mi =3D=3D 5643Mi >>>>=20 >>>> and later had "Max(imum)Obs(erved)" figures: >>>>=20 >>>> Mem: . . ., >>>> 1728Mi MaxObsActive, 275192Ki MaxObsWired, 1952Mi = MaxObs(Act+Wir+Lndry) >>>>=20 >>>> Swap: 3685Mi Total, . . ., >>>> 1535Mi MaxObsUsed, 3177Mi MaxObs(Act+Lndry+SwapUsed), >>>> 3398Mi MaxObs(A+Wir+L+SU), 3449Mi (A+W+L+SU+InAct) >>>>=20 >>>>=20 >>>> The aarch64-as-armv7 was a Win DevKit 2023 that has 8 cores and: >>>>=20 >>>> AVAIL_RAM+SWAP =3D=3D 31311Mi+120831Mi =3D=3D 152142Mi >>>>=20 >>>> So lots of 4 GiByte or smaller processes would fit. >>>>=20 >>> Absent finding a way to get --threads=3D1 to be what is used, I >>> made the following crude way to test, built it, installed it >>> in the armv7 directory tree used for aarch64-as-armv7, and >>> then started an aarch64-as-armv7 test of building devel/llvm19 >>> to see what the consequences are (leading whitespace details >>> might not be preserved): >>> # git -C /usr/main-src/ diff contrib/llvm-project/ >>> diff --git a/contrib/llvm-project/lld/ELF/Driver.cpp = b/contrib/llvm-project/lld/ELF/Driver.cpp >>> index 8b2c32b15348..299daf7dd6fa 100644 >>> --- a/contrib/llvm-project/lld/ELF/Driver.cpp >>> +++ b/contrib/llvm-project/lld/ELF/Driver.cpp >>> @@ -1587,6 +1587,9 @@ static void readConfigs(opt::InputArgList = &args) { >>> arg->getValue() + "'"); >>> parallel::strategy =3D hardware_concurrency(threads); >>> config->thinLTOJobs =3D v; >>> + } else if (sizeof(void*) <=3D 4) { >>> + log("set maximum concurrency to 1, specify --threads=3D to = change"); >>> + parallel::strategy =3D hardware_concurrency(1); >>> } else if (parallel::strategy.compute_thread_count() > 16) { >>> log("set maximum concurrency to 16, specify --threads=3D to = change"); >>> parallel::strategy =3D hardware_concurrency(16); >>> Basically, if the process address space has to be "small", avoid >>> any default memory use tradeoffs that multi-threading the linker >>> might involve --even if that means taking more time. >>> We will see if: >>> [00:00:33] [07] [00:00:00] Building devel/llvm19@default | = llvm19-19.1.0.r1 >>> still fails to build as armv7 vs. if the change leads it to >>> manage to build as armv7. >>> =3D=3D=3D >>> Mark Millard >>> marklmi at yahoo.com >>=20 >> I can build llvm18 and rust 1.79 on native armv7 without problems - = on Tegra TK1, without poudriere and on the ufs filesystem. IMHO = poudriere is unusable on 32bit systems. >=20 > On Windows DevKit 2023 in a armv7 chroot I can build rust 1.79.0 > as well. I've not tried a recent devel/llvm18 in that context, > just devel/llvm19 . An armv7 process in this context can use > about 1 GiByte more memory space than on the OrangePi+ 2ed. (See > later program example outputs.) >=20 > Previously, devel/llvm18-18.1.7 had built fine some time back. > So I'm trying the modern 18.1.8_1 now on the Windows DevKit 2023. > But this is with forcing of --threads=3D1 for lld: same context as > the recent devel/llvm19 exploration. >=20 > Note: UFS context, not ZFS. >=20 > How does the Tegra TK1 context compare for the following > program and the example command? >=20 > OrangePi+ 2ed (so: armv7 native with 2 GiBytes of RAM): >=20 > # more process_size.c > // cc -std=3Dc11 process_size.c > // ./a.out 268435456 268435456 268435456 268435456 268435456 268435456 = 268435456 268435456 268435456 268435456 268435456 268435456 268435456 = 134217728 67108864 33554432 16777216 8388608 4194304 2097152 1048576 >=20 > #include > #include > #include > #include > #include >=20 > int main(int argc, char *argv[]) > { > size_t totalsize=3D 0u; > for (int i =3D 1; i < argc; ++i) { > errno =3D 0; > size_t size =3D strtoul(argv[i],NULL,0); > void *p =3D malloc(size); > if (p) totalsize +=3D size; > printf("malloc(%zu) =3D %p [errno =3D %d]\n", size, p, errno); > } > printf("approx. total, a lower bound: %zu MiBytes\n", = totalsize/1024u/1024u); > return 0; > } > # cc -std=3Dc11 process_size.c > # ./a.out 268435456 268435456 268435456 268435456 268435456 268435456 = 268435456 268435456 268435456 268435456 268435456 268435456 268435456 = 134217728 67108864 33554432 16777216 8388608 4194304 2097152 1048576 > malloc(268435456) =3D 0x20800180 [errno =3D 0] > malloc(268435456) =3D 0x30801980 [errno =3D 0] > malloc(268435456) =3D 0x40802640 [errno =3D 0] > malloc(268435456) =3D 0x50803600 [errno =3D 0] > malloc(268435456) =3D 0x608048c0 [errno =3D 0] > malloc(268435456) =3D 0x70805140 [errno =3D 0] > malloc(268435456) =3D 0x80806580 [errno =3D 0] > malloc(268435456) =3D 0x90807780 [errno =3D 0] > malloc(268435456) =3D 0xa0808700 [errno =3D 0] > malloc(268435456) =3D 0x0 [errno =3D 12] > malloc(268435456) =3D 0x0 [errno =3D 12] > malloc(268435456) =3D 0x0 [errno =3D 12] > malloc(268435456) =3D 0x0 [errno =3D 12] > malloc(134217728) =3D 0xb0809a00 [errno =3D 0] > malloc(67108864) =3D 0x0 [errno =3D 12] > malloc(33554432) =3D 0xb880a5c0 [errno =3D 0] > malloc(16777216) =3D 0xba80b0c0 [errno =3D 0] > malloc(8388608) =3D 0x0 [errno =3D 12] > malloc(4194304) =3D 0x0 [errno =3D 12] > malloc(2097152) =3D 0xbb80c180 [errno =3D 0] > malloc(1048576) =3D 0xbba0de80 [errno =3D 0] > approx. total, a lower bound: 2483 MiBytes >=20 >=20 > Same program with same command on Windows DevKit 2023 in > armv7 chroot (aarch64-as-armv7 with 32 GiBytes of RAM): >=20 > # ./a.out 268435456 268435456 268435456 268435456 268435456 268435456 = 268435456 268435456 268435456 268435456 268435456 268435456 268435456 = 134217728 67108864 33554432 16777216 8388608 4194304 2097152 1048576 > malloc(268435456) =3D 0x20800b00 [errno =3D 0] > malloc(268435456) =3D 0x30801600 [errno =3D 0] > malloc(268435456) =3D 0x40802cc0 [errno =3D 0] > malloc(268435456) =3D 0x50803c80 [errno =3D 0] > malloc(268435456) =3D 0x608042c0 [errno =3D 0] > malloc(268435456) =3D 0x70805b00 [errno =3D 0] > malloc(268435456) =3D 0x808063c0 [errno =3D 0] > malloc(268435456) =3D 0x90807580 [errno =3D 0] > malloc(268435456) =3D 0xa0808b40 [errno =3D 0] > malloc(268435456) =3D 0xb0809980 [errno =3D 0] > malloc(268435456) =3D 0xc080abc0 [errno =3D 0] > malloc(268435456) =3D 0xd080ba00 [errno =3D 0] > malloc(268435456) =3D 0xe080cc80 [errno =3D 0] > malloc(134217728) =3D 0xf080d700 [errno =3D 0] > malloc(67108864) =3D 0x0 [errno =3D 12] > malloc(33554432) =3D 0xf880eb40 [errno =3D 0] > malloc(16777216) =3D 0xfa80fc00 [errno =3D 0] > malloc(8388608) =3D 0x0 [errno =3D 12] > malloc(4194304) =3D 0xfb810840 [errno =3D 0] > malloc(2097152) =3D 0xfbc117c0 [errno =3D 0] > malloc(1048576) =3D 0xfbe12940 [errno =3D 0] > approx. total, a lower bound: 3511 MiBytes >=20 >=20 > Note: If the Tegra TK1 in question has more than > 4 GiBytes of RAM, the command line should explore > more than the example that I used. >=20 >=20 > Note: I've used the program for other patterns of > allocations. That is why it is not just a fixed > exploration algorithm. >=20 >=20 > As for poudriere-devel, I find it useful, even on > the OrangePi+ 2ed. But mostly that is a rare run > that is checking on how well the handling goes for > the 2 GiByte of RAM context (with notable SWAP for > the size of RAM). In other words, monitoring the > growth in a context that will break sooner than > my other contexts generally would. The tests take > days overall, most of the time being for rust and > a llvm* . >=20 > Historically I've been able to have 2 builders, > each with MAKE_JOBS_NUMBER_LIMIT=3D2 , so all 4 > cores in use building lang/rust and a devel/llvm* > at the same time successfully in poudriere-devel > on the 2 GiByte OrangePi+ 2ed. (This was before > recently imposing --threads=3D1 experiments, > given the recent build failures.) I should have noted that my normal devel/llvm* builds on aarch64 and armv7 avoid building: BE_AMDGPU and MLIR . They also target BE_NATIVE instead of BE_STANDARD . (aarch64 BE_NATIVE includes armv7 as well.) =3D=3D=3D Mark Millard marklmi at yahoo.com