From nobody Mon Mar 11 15:50:33 2024 X-Original-To: freebsd-ports@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 4Tth7t1jVRz5DCvf for ; Mon, 11 Mar 2024 15:50:50 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-20.consmr.mail.gq1.yahoo.com (sonic305-20.consmr.mail.gq1.yahoo.com [98.137.64.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 4Tth7s25Grz4ZQk for ; Mon, 11 Mar 2024 15:50:49 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=Akdjmg44; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1710172246; bh=fxsSCsn9lnPQq6qOGFCjFdzC3anBUkElDOUDtLHaWWE=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=Akdjmg44hbBYs7NTHGBsUM957LEKozUuthqg2XgLEbGGrM6a7mASAvirW1+Ri6lo5n9qdneiRiGXBKUC1h9I1rC/e2lUQaZ/T57or6hikfuSOICM1UcAMFdUyVznNuCYn4ljgs2KOguUpP7xdXLSBjiIJqZ4UBXzCTyra4Fx2hXtkH94GbQVUfxg9ycom23UKX575gk4CIw/6GYYlU8L/wNlm+2crkjxjPXuKQrwEjbiSgTAe8QzoTkdLPkRKz1BrqJvzsPB3tOH9rUUYXvrDr42ii2ZS4frR3r/5pxfwbKot2mOegicB5/B5pzV0mIkWpbD4kdGvnFKpulhAUogFg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1710172246; bh=M/aoVvpoab925TRETSBuo2UJKDDGG2pQz1Lv050zJJ2=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=Sw31/M5g33HPR9ZDLL0+NWCWQEGdkJpCWqsOFb6jQEq9BKXVtVk2PtMjgIfqizde8emqGGf8Cj8LZmv8Ic2QLcC9cn1EWrtLZWwz6ex11DDfxqPPbmQ9UUPzHABo8xRKRpaXv8UCuXEVZ8e607V08wtV+iDl8Cye/OgxkrlBgclvM1gMR6iwH3Vd8wDZApGlOc1zmqZTvJodgfPGN43XsaQvbzLvJMYagIFCRBKCseIG+dalO67xuHV56qaJ8NPYxKilHSkOwode1bMsB1PNa1dmKaPBkXwUX/aXMy7BGoIrDv7lHHYGK8Po0uXhJLByDABrZaK0L1Uq2rhpd+aihg== X-YMail-OSG: mLB2Ga4VM1mZ6VKRWQDceSMEbfPSF5cxNn_6wVjbbC8xKri7Wu7tZAFzfZ_0ViJ sx1pfAIH3YUhjp8nqfiLoS2Po6pCEoxmKkfA3t.rQxzp4JfEWXBuu6KU_CVUJXDFHZhQN4Zp_fXs ZhKzkZTKPyCTzg6tkBwQlzzx7OiwDtHvJ08HXoWbbIXZy31ieS6qliAY4Jp49EJt21lWwY_QeOyy 1khqOn2bBU8io_3YnYlQgUcljDeq37M6dgdZbeTg8a1IMl21n4OdE4rXggEs9iHy0qIJXaHDRdDC nu6ib.7cd6xU7Ib4TjmC8vJDcxeFkaJ.S5FPG_PfdEdzSgIHlugbRVEHa8bM_rHKJGyooOZII_Hd p8Tt5Wr98j7QYRCdAseHHd17SuwHk4YGlfJmDUVXL6oV5QPq6dze1gXCUk6PJz6LT11qByBKAgsO nZFxhOC70OsTwOnjRKabZSOwunArqUpjaNbxnGlvag9j0yl43bj.ZUJh5UEfDFDWocA_I_0kZW_p FnhjwmoAWYRduTEMKArJ5BGyQwewH7tWE5VEDUGCRU4aBki7OarC6Pl2XEzgbiXiuP8cEz6cY.g1 YrhyS9WrAhWO.X6rk_PCQyIBrq7jN4UC5LQzxBxlPjdMTuqmoIebgfkP32Rl.oaGUtDV2obc.fY0 qWeTiEk5CU0pGbBRz3WU_e2hcKTT.5aD_yeGhqHqyq.7F8UNzAQGXlrFd.JnALA4EiXMb1w4_OZe ZKxuvl2NsPrrRJIsnN9d881imBoEjcyefST.G_1Iw7AYXoYPXh4zhyeKFuYceiUNvUCwMO_IMmhv OPxXlViMtljp5RFR2HW2o11xiAKJUmzxMLGB1DhsMv6iQYcZQDmgQZSBaCBrusfKuGA9IPZTB.gp Gd8L60VKcxs7V5.CL8MJp3oA0THrbkyqDl_Sx_.wH5G3yY75eDd_AFwMIXBllrxl7hRYCBQtaEGG 0EeqhFi.zblT8ja3I92wTBN_oq4FIeSDwEXZnFYjh9MJ8UmoURdA.4GiWdV8Pi125XOK_waCAhVb A381gO3kSynOgEj4iUZSJvHoHoyrmD6O6AOaJcAUHKUcJOH6u9mfxz4PvPwjuL7cskSNeT17nfis WTAwCu0fWXHj7XkAnqri1zz8bWCv2Sa05p_vhIQflGvL3e8ziLCVXKJ2HKxR.ULpQjPQLMIGJLNq l1_MvBzuYi5Eqe6YJupU8S1K9_n0gyMnL2A6cZhMckDa7xAZWNgTKzIH4uRbx.RjL2BUONbAcb8j wfc58XCJyrDeV7X0w1D.7AbSspoJKcaz6abunJIL3mYk0qc5P8_GDlQvVGg2Aht96MB2iaFBD2jl xObgzQqFPueb9UpyYvc1hbDslT9b7OZ0DtSqSdIUdoKKfIOoYGENLE03yx4xt_FS2pDOl6FHjpU6 bAn05ncDjexXj82NHivZ_.tXqDPr_Z.AjUtJYQvIZa0XzDECO5DpYUhZtSvlqJsJb2GH2O5GdPrl yjs881i_yu0N2VGI2IZDuHRj7v7cm3AL9epCja00m2LZ932PK8RCaNwW_2jDB_PaoJUsB9SYMuHM eisaeaXUDGa_UVTygEglutpp6lm.7U3hFNmLBumIlvCLOXN.Jcm3hWxt3zMC8aP6evBTifm48PSV 3nejTH6KjiYDfDCEdkT5_4IhvUhlCpUD31NE2Z0vsm8YrvWOwregR35TNlrEQYkf6UazeZqp_AtS ueX81orT0dOkVDsJh_b9A9zKfXP.LD0eL93duRz4NFbSt4yEwok1cVixaH1Rr9pm7XSJJ.8wsgn4 lcEk08mzoRJ3eYXnodVAbUaO91qhMqUu8UoKH3Vg21gLHK7Eucy2pnAwf3Pfk63_mMJ3RaW7HZxf szSb40OkNTlGJ9dxPSPYPeWxMlm5dhUkpMR.Uyqh5sNAoE3GZad6uelP_uBW.UllVjuQq1LX3zl7 LU9wY8FBoT4DqT3jjaQUUaUdNP5bpfTDaVqJ4_7IK.XNTZ70meDhHHdmH4gg65uaZmmCB_SbVgD. tclmDz522Pi3KAGS.BTf0rwmz5SCTDnok_felYK0M6yBTEbB0PRQeXJo7PrD8bCUf5sTqLavMFlo 6QCth9k478CkX7pt4dR6L1NaXTfZs8W5_tgNsQnrupWtppx00evvdhSLcnaCxKfM6Hr_YxfSXfRu IWeT9NwMjC33j8OqZ8humw3H8iLGqJ87Ah0Z4Opo1ZzDCFMd5AjyzZmTaiTezbnWZjLH7rQQvJbt dUnuPahkFnJuLy1tJwc2VqK7fpRQKM0AzMh6y3HbeSJyUREAAvsLOtfb0 X-Sonic-MF: X-Sonic-ID: 444bae43-4733-437d-b9cb-6fffee746e90 Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Mon, 11 Mar 2024 15:50:46 +0000 Received: by hermes--production-gq1-5c57879fdf-7xbd4 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 10e14b136b4f72b905d558abea19a4b5; Mon, 11 Mar 2024 15:50:44 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.400.31\)) Subject: Re: FreeBSD ports community is broken [port building configuration notes] Date: Mon, 11 Mar 2024 08:50:33 -0700 References: <87B38D6C-1D83-4158-B03B-F4C8EA396DD1@yahoo.com> <4A386631-E8FF-4640-A927-46DE38F07F00@yahoo.com> To: FreeBSD Mailing List In-Reply-To: <4A386631-E8FF-4640-A927-46DE38F07F00@yahoo.com> Message-Id: <3680E93A-0E85-4E48-BE78-7B3C283AB399@yahoo.com> X-Mailer: Apple Mail (2.3774.400.31) X-Spamd-Bar: --- X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; 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]; RCVD_TLS_LAST(0.00)[]; TO_DN_ALL(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCPT_COUNT_ONE(0.00)[1]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MLMMJ_DEST(0.00)[freebsd-ports@freebsd.org]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.83:from]; APPLE_MAILER_COMMON(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.83:from] X-Rspamd-Queue-Id: 4Tth7s25Grz4ZQk [The armv7 poudriere bulk finished.] On Mar 10, 2024, at 13:10, Mark Millard wrote: > [poudriere bulk status update.] >=20 > On Mar 5, 2024, at 18:43, Mark Millard wrote: >=20 >> [I noticed that my SWAP figures were not self consistent for the = armv7.] >>=20 >> On Feb 18, 2024, at 09:50, Mark Millard wrote: >>=20 >>> [I also forgot to mention an important FreeBSD configuration setting >>> as well. It is not specific to poudriere use.] >>>=20 >>>> On Feb 18, 2024, at 09:13, Mark Millard wrote: >>>>=20 >>>> [I forgot to mention the armv7 core count involved: 4] >>>>=20 >>>> On Feb 18, 2024, at 08:52, Mark Millard wrote: >>>>=20 >>>>> Aryeh Friedman wrote on >>>>> Date: Sun, 18 Feb 2024 10:37:06 UTC : >>>>>=20 >>>>>> It should not require >>>>>> prodiere running on a supermassive machine to work (in many cases >>>>>> portmaster and make install recursion fail where prodiere works). >>>>>=20 >>>>> As for configuring for small, slow systems relative to >>>>> resource use, I provide some settings that I've >>>>> historically used below. Then I have some other notes >>>>> after that material. >>>>>=20 >>>>> For a 2 GiByte RAM armv7 system with 3 GiByte swap space >>>>> and a UFS file system, no use of tmpfs in normal operation >>>>> (since it competes for RAM+SWAP generally): >>=20 >> Actually: 2 GiByte RAM armv7 has 3.6 GiByte SWAP space, with >> some margin. Ever so slightly over 3.8 GiBytes got the mistuning >> warning but there is variability across builds so I try to avoid >> repeated adjustments by picking somewhat smaller. >>=20 >>>> FYI: The armv7 has 4 cores. >>>>=20 >>>>> /usr/local/etc/poudriere.conf has . . . >>>>>=20 >>>>> NO_ZFS=3Dyes >>>>> USE_TMPFS=3Dno >>>>> PARALLEL_JOBS=3D2 >>>>> ALLOW_MAKE_JOBS=3Dyes >>>>> MAX_EXECUTION_TIME=3D432000 >>>>> NOHANG_TIME=3D432000 >>>>> MAX_EXECUTION_TIME_EXTRACT=3D14400 >>>>> MAX_EXECUTION_TIME_INSTALL=3D14400 >>>>> MAX_EXECUTION_TIME_PACKAGE=3D57600 >>>>> MAX_EXECUTION_TIME_DEINSTALL=3D14400 >>>>>=20 >>>>> /usr/local/etc/poudriere.d/make.conf has . . . >>>>>=20 >>>>> MAKE_JOBS_NUMBER=3D2 I'll note that I'd switched to using MAKE_JOB_NUMBER_LIMIT and do not use MAKE_JOB_NUMBER any more. So: MAKE_JOB_NUMBER_LIMIT=3D2 >>>>> /etc/fstab does not specify any tmpfs use or the >>>>> like: avoids competing for RAM+SWAP. >>>>>=20 >>>>> The 3 GiBytes of swap space is deliberate: RAM+SWAP >>>>> is important for all means of building in such a >>>>> context: there are a bunch of ports that have >>>>> large memory use for building in all cases. >>>>>=20 >>>>> [armv7 allows around RAM+SWAP=3D2.5*RAM before >>=20 >> That equation should have been RAM+SWAP=3D=3D2.8*RAM >> (with margin considered), so SWAP=3D=3D1.8*RAM. (With >> a small enough RAM 2.7*RAM might need to be used, >> for example.) >>=20 >> So the 2 GiByte RAM leads to a 5.6 GiByte RAM+SWAP >> for the builders and other uses to share. >>=20 >> I may set up a modern experiment to see if the >> combination: >>=20 >> PARALLEL_JOBS=3D2 >> ALLOW_MAKE_JOBS=3Dyes (with MAKE_JOBS_NUMBER=3D2) Again, now: MAKE_JOB_NUMBER_LIMIT=3D2 >> still completes for a build that would end up with >> llvm18 and rust likely building in parallel for >> much of the time (if it completed okay, anyway). >> Something like 265 ports would be queued, the last >> few of which include some use of llvm18 and of >> rust. >>=20 >> . . . >>=20 >>>>> tradeoff/mistuning notices are generated. aarch64 >>>>> and amd64 allow more like RAM+SWAP=3D3.4*RAM before I've not validated the 3.4 figure. It is likely a bit low. >>>>> such notices are reported. The detailed multiplier >>>>> changes some from build to build, so I leave >>>>> margin in my figures to avoid the notices.] >>>>>=20 >>>>> I also historically use USB SSD/NVMe media, no >>>>> spinning rust, no microsd cards or such. >>>=20 >>> /boot/loader.conf has . . . >>>=20 >>> # >>> # Delay when persistent low free RAM leads to >>> # Out Of Memory killing of processes: >>> vm.pageout_oom_seq=3D120 >>>=20 >>> This is important to allowing various things >>> to complete. (The default is 12. 120 is not >>> the maximum but has been appropriate in my >>> context. The figure is not in time units but >>> larger increases the observed delay so more >>> work gets done before OOM activity starts.) >>>=20 >>> Using vm.pageout_oom_seq is not specific to >>> poudriere use. >>>=20 >>>>> As far as more ports building in poudriere than in >>>>> "portmaster and make install recursion" in other >>>>> respects than resources: it is easier to make ports >>>>> build in poudriere. It provides the simpler/cleaner >>>>> context for the individual builders. More things >>>>> lead to failure outside poudriere that are just not >>>>> issues when poudriere is used so more care is needed >>>>> setting up the ports for the likes of portmaster use. >>>>> (And, yes, I used to use portmaster.) The required >>>>> range of testing contexts is wider for use of the >>>>> likes of portmaster to know that the port build will >>>>> just work in the full range of contexts. >>>>>=20 >>>>> Such issues adds to the port maintainer/committer >>>>> development burdens when portmaster or the like are >>>>> the target level/type of support. >>>>>=20 >>>>> (Note: synth may be more like poudriere for this >>>>> but I've historically had use of platforms that >>>>> synth did not support and so have not looked into >>>>> the details.) >=20 > Context: 1GHz, 4 core, cortex-a7 (armv7), 2 GiBytes RAM, USB2. > RAM+SWAP: 5.6 GiBytes. Also, this is doing my normal armv7 (and > aarch64) style of devel/llvm* build: OPTION'd to BE_NATIVE > instead of BE_STANDARD and OPTION'd to not build MLIR. Also: For armv7 I use -mcpu=3Dcortex-a7 most everywhere for each of: port builds, the world in the poudriere jail directory, the booted kernel+world. (All armv7 contexts that I've access to support cortex-a7 user space code.) In poudriere.conf I used the likes of: PRIORITY_BOOST=3D"cmake-core llvm18 boost-libs gcc-arm-embedded" and probably should have listed rust after llvm18 as well, making it more likely that the 2 builders will run in parallel much of the time (less elapsed time): See the later summary time frames. > The poudriere bulk has finished llvm18 and rust,=20 . . . updating the related material: It finished overall, in somewhat under 5.5 days. The "what builds took over an hour" summary is: [01:51:31] [01] [01:00:07] Finished lang/perl5.36 | perl5-5.36.3_1: = Success [08:55:35] [02] [03:08:09] Finished devel/icu | icu-74.2,1: Success [13:17:38] [02] [01:28:32] Finished lang/ruby31 | ruby-3.1.4_1,1: = Success [14:17:44] [01] [09:20:55] Finished devel/cmake-core | = cmake-core-3.28.3: Success [4D:01:03:43] [02] [3D:08:48:53] Finished lang/rust | rust-1.76.0: = Success [4D:06:26:24] [02] [03:09:35] Finished devel/binutils@native | = binutils-2.40_5,1: Success [4D:14:54:31] [02] [03:38:55] Finished devel/aarch64-none-elf-gcc | = aarch64-none-elf-gcc-11.3.0_3: Success [4D:16:13:00] [01] [4D:01:55:03] Finished devel/llvm18@default | = llvm18-18.1.0.r3: Success [4D:18:05:58] [02] [03:11:00] Finished devel/arm-none-eabi-gcc | = arm-none-eabi-gcc-11.3.0_3: Success [4D:23:00:13] [01] [06:46:06] Finished devel/boost-libs | = boost-libs-1.84.0: Success [5D:00:16:39] [01] [01:15:53] Finished textproc/source-highlight | = source-highlight-3.1.9_9: Success [5D:01:17:24] [02] [07:10:52] Finished lang/gcc13 | gcc13-13.2.0_4: = Success [5D:09:38:14] [01] [05:56:48] Finished devel/freebsd-gcc13@armv7 | = armv7-gcc13-13.2.0_1: Success [5D:10:18:58] [02] [05:44:02] Finished devel/gdb@py39 | gdb-14.1_2: = Success [5D:10:31:56] Stopping 2 builders [main-CA7-default] [2024-03-06_03h15m10s] [committing] Queued: 265 = Built: 265 Failed: 0 Skipped: 0 Ignored: 0 Fetched: 0 Tobuild: 0 = Time: 5D:10:31:55 >=20 > So: llvm18 started before rust and finished after rust, each > mostly using 2 hardware threads. About the last 1.5 hr for > llvm18 was llvm18 being packaged, after somewhat over 96 hours > of mostly 2 hardware threads working on it. The vast majority > of the build time was for the build phase. >=20 > I have a modified top that monitors and reports some "MAXimum > OBServed" figures (MaxObsYYY figures). As of llvm18 finishing, > that top was reporting: >=20 > 2794Mi MaxObs(Act+Wir+Lndry+SwapUsed) > (Inact can be an arbitrary mix of dirty and clean pages and, > so, is not included.) >=20 > Swap: 995524Ki MaxObsUsed The MaxObs figures reported did not change. > Thus, it used up to around half of the RAM+SWAP to get that > far. (Rust and llvm18's peak RAM+SWAP usages need not have > been over the same time period. But there was RAM+SWAP room > for a larger overall peak.) >=20 > [Note: The peak RAM+SWAP use was during a period of llvm18's > build running various llvm-tblgen examples.] >=20 > As stands, it looks like the poudriere bulk run will complete > just fine for the configuration that I specified, with margin > for variations in peak RAM+SWAP usage. >=20 It competed just fine. =3D=3D=3D Mark Millard marklmi at yahoo.com