From nobody Sun Mar 10 20:10:25 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 4Tt9yG3yPQz5Cmct for ; Sun, 10 Mar 2024 20:10:46 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-55.consmr.mail.gq1.yahoo.com (sonic316-55.consmr.mail.gq1.yahoo.com [98.137.69.31]) (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 4Tt9yF3bVjz4Mt1 for ; Sun, 10 Mar 2024 20:10:45 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=LLLXmIrE; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1710101442; bh=ErGZUhkhY0dSdd/0bTYFt8PcpweAOhsjAb2UrCdHKXo=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=LLLXmIrEiJ5rZ1nBgzmVXBzFGq7BFVj41HRD+BSbWx9ZcCt3tU/lFt1Iz1KQcZxYD3QOYI4oo9o+z8kow674f29qnkACQdh4bH7Kgtv8bkf1gvCafPXyhyQNSfI7a2Xzr7p7/ZduCcxYCNqGrShM60oRKoYSlaS0pstv/ZDolSw33C7DEHsIdJImoSHJv30MW4dV8N9r1VdfWzGqHiipN81mYpBBrZXB0qnln8fTlvfcU+fDPpQnXaHn3KUnLYiWJD98YA3XAqys+8BeMbMR/JOgn7o/GyhqVWl1mUeYhWhF18NtMJvlq3MUD38NA2PbEiEtJ3ZO8mwn1z8XMIHucQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1710101442; bh=eGfwA2/mANRL1i7ikGB57bC9ZtiDGhiaWllShiIBp+W=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=EhhYlHUBXAcgl6GXQs5cGOKYBjCALob5TyNb7Osj5M46Ih3BirOk19f/q+30o3H8DZKrht8XUFhHgpbTIWvwDQ+HLxlxbPJ3s0vUuYclrsLlIqpNIaW385osuuJ7XJo3y29i7QDwp0LBEOWBmLmNwjoe9/680LSiZJYIAGiWbrAl6Y7Wwl8wavkFloWhTNt+EJTNsiYRZjxZWVcG6U07qtYEjSdb2onp/WCsby4AFB1NDBb/ioqNY+3OvnSq5Jvt135k4+HIpkY7wq8uXRu2eT52LSbVPoIutvrtIGNNeUuqdYIh6Pz+i6W9dEqXygeX2fguo3Gyy8PmPnd94pND3g== X-YMail-OSG: iVgsQK4VM1nqPT6RJXEkw2kgN.9Jbdufd1r3FovtO7fBNrtFbuPLZkdEkfm59GT 4m1odaP5E2VL2BPy0Yhn9CZopC7_M_axISvj3OkQnHhoQF80XJVqK5gTdqddBON2qYbsvPvOQ4HT bn5EgdDcHWx5j7B3QTkKjGkuyOGDecbL81inDE5YDxiMZCTHJ19RkdhB_HhrgRk_AfEvKm8iCv4H NARLVWE5k3fg6I48q..Iy59LEaeM24CtXusD4wO2Cjq7J93vG9YL.MlWmCH0Bkt0J7RARWXqitpM IxwzkNju.f23.8hhJTNA6b5dRNjZyAAzcUybnzESDuVuF8ZPhkEvRW7QVCPETl2GvImYErvoo6Bz IsAmv777bxHh2Wnp1da5t6FfSLj0dCX5BkFTBan_1tJDeMOHjNqkUqskOPSi8Zy3XHfSKIDOqeJB 0GtdDhH83ReO1I_rmqMovFPMI9JDNw9cjkd5zToBetkZr8HU_IUHQbeasoro2x_IqFFe_gc9vmPD iYmMaoHupibaEkJS90z1MfzNQwCzciXxaBzLx7.BXpaBkCwOkbI0CZ9jX5.0KjD0sL4qcSh19Nef .UVaNWDH1Q03ExfrzuUoJL_PZ6iq7JKRStrefO9ZguAFTFJvYcQo0wjNv1HbNejco7Nohh.d33sS CMp2qS.BFeZaBc0pY83V3CTdA7PWC16VKxuwn8bP.dHbfqKGgqtrR9XKAY38PGxfmIThdBSxT5HJ wEu8j9YPbycw3ldYTPapJx5GS1kMNPvixBbh84NEmyxEuLD2twOJl6EqAon9U2symyyV0QGSKvok RZCgDk_h8zFxNIrQ5qVaUNxksla8S8q_vSF2ApxiDaKEkAlEnWcKBYkH56OdNhLK.gwuslGCxPoc P7EjYfu.YZa.7oNk.JDvChSjj213h2BOg2bkx_rzOEcwTTKbU.zVE1sZKW2vO_P2BDeXDDcPKIJ. D71xAiQTKME_mUKwaxa4n46qYyHwejXOKMUiUvOdgf.L2_cwYr7UdcQ_iglGNJ1S2LXQB7ROYeGH rS5lAOIcStT2nPY8CtoL9MX8V5UJ2EuI_CNhk4Z2HpONuG7lm1rExdKoq7QVf4g1jLmvpu7SRC4_ LFJWFyxwnGNIgn2TqkDs7JEeOajuTjTgMJLy10IO3fgze_60VF0KfCWHLl_8u.gaUXLABB7irb0z 1mzBGspGy90_wYTiXo2atfymnjbi_E1XbF31DiZX7OMvJHqnApGrdF6f4O2xJdM5GS.0AbuZA2CQ fdcZGkICeURxrsGsOFxppk7COJd8bdB2EMnzfSPldMnup1imWp.dvdfg7NJnaj9yJF2l_.helhua 5kTHJ0uw4xwFV8dE1lFtR9lmSQgi11mRvSZcuGU_HgvftsCXjhucF6HGOQ.AbaQFjYwsQIb2c_oq WeoNbSl.owDXuKQZgmOYeEIZoe.At5Amd9.xQ2j_cl1UKMfaA7xsFdjksu9a3kaNaN13WmbH5k65 yWWRdINosz0C1iHHGINLng5AgKkixF3gSzKq2DtFWVYRORW8lh1FHl9zYq1lPx0RGQe9lgkhxLOC 3WY1ApylWXxph.Bj6Kv689gPWlo8jgdJp8oD4KFAVDn3mW2MRwiD56Xhw.lBtSzU49oLirDIcIDT twjjS7f2osLgB3b.jOExi.807O9Y0W47vUQbOF5B9nEda5d4aOmcfptB_vFJ_9XuBAlP4tn3EfeE R0Cfi89EdPh4BNq.HsHWnuUuxt7LOqYPxV87jMnwTdijOpuYW8wL9gMgyktXyLOP2flUIjU2BPtP O6nY9DEqfQAk63VLSnF_75dqfvARNxyn1B1bwLdqq6bgW4ymswU0ud3jMVX.G4jYChRpnvG5kq5g hJdy711l9sHVYAkrEot45WO3Hd2qCcQX87s1OVGcw3r4BD4zNPLQnS9ED8csMbxIf9OZP6VBZavt vDQhD7u01h2Ygf9WZHm.g9f85WuR23lvXoaDbneGpyj54d1HJcyTThJZWwuTt0loxT4x7LCXBvx4 FRy9hvRbKo05zol1dQNfCoQqguBi250_PG64I0cDBIIwLMyDGq1zAJA6_o.TFVaq.Cyrh74Rylbo oZGjQvl6ywqlsdkQjUuD_GZ0LBYePB7O7BDFk0qOecgoxhwg48Dda8JqN7gXxOIM9fkp_NLLJmNq sm4ShdxYQQA9FSlbcgkbIN0hyQD8ZgbofRT61UxieswCoh3k9wr3NF9NeYzQ334.3bHxUJfR.CBU p6mEifsc7VdaxF_3utH2AZpqGGt2G7D5V9LL3.ob8ufG_vEUsOV3rSjuwOA-- X-Sonic-MF: X-Sonic-ID: 52dfb650-dc18-4115-b72c-2c0adb0a3f37 Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Sun, 10 Mar 2024 20:10:42 +0000 Received: by hermes--production-gq1-5c57879fdf-qprqq (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID f2408d2affa7ef35e1612a03b9e12b03; Sun, 10 Mar 2024 20:10:36 +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: Sun, 10 Mar 2024 13:10:25 -0700 References: <87B38D6C-1D83-4158-B03B-F4C8EA396DD1@yahoo.com> To: FreeBSD Mailing List In-Reply-To: Message-Id: <4A386631-E8FF-4640-A927-46DE38F07F00@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.69.31: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.69.31:from] X-Rspamd-Queue-Id: 4Tt9yF3bVjz4Mt1 [poudriere bulk status update.] On Mar 5, 2024, at 18:43, Mark Millard wrote: > [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 >>>>=20 >>>> /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) >=20 > 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 > If it failed, I'd revert to using PARALLEL_JOBS=3D1 > and MAKE_JOBS_NUMBER=3D3 and see how that went. > llvm18 and rust would no longer build in parallel. > If that also failed, I'd revert to > MAKE_JOBS_NUMBER=3D2 . The last option would be > MAKE_JOBS_NUMBER=3D1 . >=20 > It has been a notable time since I last did such > an exploration on such a small configuration. >=20 >>>> tradeoff/mistuning notices are generated. aarch64 >>>> and amd64 allow more like RAM+SWAP=3D3.4*RAM before >>>> 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.) 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. The poudriere bulk has finished llvm18 and rust, having built 206 packages with 59 to go. Summarizing via package builds that took over an hour: [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 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. I have a modified top that monitors and reports some "MAXimum OBServed" figures (MaxObsYYY figures). As of llvm18 finishing, that top was reporting: 2794Mi MaxObs(Act+Wir+Lndry+SwapUsed) (Inact can be an arbitrary mix of dirty and clean pages and, so, is not included.) Swap: 995524Ki MaxObsUsed 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.) [Note: The peak RAM+SWAP use was during a period of llvm18's build running various llvm-tblgen examples.] 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. =3D=3D=3D Mark Millard marklmi at yahoo.com