From nobody Mon Mar 11 20:05:16 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 4Ttnnn00Xfz5DcGc for ; Mon, 11 Mar 2024 20:05:33 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-21.consmr.mail.gq1.yahoo.com (sonic305-21.consmr.mail.gq1.yahoo.com [98.137.64.84]) (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 4Ttnnl44yjz52RM for ; Mon, 11 Mar 2024 20:05:31 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=SYXGmXdy; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1710187529; bh=apsNMV6mlwpto0/8svX7XbumjvHBvubzTh1f9cwLxz8=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=SYXGmXdyopHbByZnWGHZmV6u4P4SICKEQmVtDuuVjTAHQVWv0DCBBRy5nzZD6gi5mS8Z48VjKpCpg8e2fSTKrpg2qwEXmDqQjpyZiB7dWR9RSOKk56yB6yP9U3IyQzp2LzV93e2Gq5OsiPz46cpsmRY5fvvJz9EkMYGybxpP/O6b8pB7FKqHSm1FUx9yhNU6jScYpI5US6U4Vj+Wp5mTyY3keKTvUwsOXOOnFXiptwBLEaDL0lrUtyMeHLu70ZlrXeLw+MD2ejaY3f/0UEripmPScOa/ojjOIc6vmvwS3GCTGk6TzUc+jrW8BdKW1v6AHF7MzM8T48dtepraEgdNbg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1710187529; bh=X5je9uqVrsYEvi67hkXLD42hXBmCsiJZC1eZE2khNaw=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=q5q4ZU9oFzvMIdEEY5X4GX7SBcUxxdn9cHbcjUsyicC9oenQyMAoQe1R+PvE0JtdBxxW6tG7/Dwh0HPyFUfMhHAbOmGJnE8Jy6OvO08GvU1lrzMzj5ofU6DyF6gETdWhONy6PjRBmJm3GFrpc3rPjb28WxKWHIkAqYX7gKFrF0BdaY8DiZlapbN9L3XTFCx9Cy9Saa+CupeO5/BqbpXRJguza5JSugvKTrAcVCHZqPjpUxeZoVpdfXtIoX5/I7hzcGTKYtkW0FTIFlAM895orrQSmGk04PbRcBwXzqNzs4xB0yUvj9YE+/RBV7EGsrUF8wBPq3uWy1NUndtj+q8oBw== X-YMail-OSG: ZlPzCZcVM1lzlj5Fj2ifmlsPq0ul85rT11xt44qUP6keH7lo_7mWJMx1QWpp3be jGKAXIB5hK4l73wqH63ChHGF8eLrYcaZ6FMS5Myjtx0ZcqBUXnufK9Fw5axVNMEysmXAMPkk05p6 uHGyD8LpRUiKrI3AGWJ_.8xAOHAByLdRUJLkt2ADkEgmpuh_khgl_wzJ18w.LK2EtCF9epSJbNKI w3l6uC5wrr6vGn9tbzx_wgi4WxBGCqapbiY2oKNqppuJM2ewBG9YG.39KMpcc5hKOz4tL_SyM0W3 hH_pq3ml_KcJUUGJtWHc0UARZGcfVS7T1a1FRZBY.Lm1Ol7SbMyftJ.NuGcs5GBltDrB8V29FaP9 lHlHJxWdneJfbExDBs2JWp3SN9sr67sCY6bU6BWds8tLmWoPTlYGxSvxePfBMNh8wyNB0Y9Ps6j8 YifWQRfa1MXkld3Rs38LvC5zBZ1NLhXMp2l3HfE6Ua3wvzOJTblX3RhYvVAiKwCLYWIGjfg61uiH f4Wvzq5um6o9TwoiflPUtgaMUs1mu3_1W3f1SwLUEGrWluybreXnAYMkwO6hpsGRWWUXX6A8dKIj K8abahrZ4wnjLl8KgWPUmDXE47iyazElch1yMnPWGsCkVFDsRdlLSdstCG5jvNJ2mDGFDPZVINtS GYldpPhO8TtuVmd7WGVC_kpDxsjlaVByVJLJZmlBRHyh2TPqvTa_iNYmr5eLZZW9C7ZbXr_WHRAk ek7H0RKVoGCRxrfRyvUyozFKwdyOApBKZHTe2_drBOlOjIgwsl5T3tQW8_VqbunPwueiauZd18Dm R.FMg4grc.qu_2ONNzuqUroN26ph6tgGEXy1x8ttPAeSirbM9gC.UzOfmGslPTsXl7Hoqoj4GSJp M2GIrZaAwzsTJTuaKifvP5dh2b9xrQz0bb1xzO18OGJDhUukNVrALtQ12p3lU22tArTSacA7E0CJ 4A39305WaVG73xPcXd36Ddk99DcUV0IjakhC19S_E95VJowTFH8qurAmqBVwgMYVey.1Tk_ulM.N wtOYDgQlQP6oFPdu7X_Rr.9kTcG3jPYGzHFduD0sRTFS.u0p3nkLDMYb1yUFTG0WJ7_Tg6VgeaHR 6Kzq09_ahOy8oapGG3OLASmV3mfsD_ZMcxzm9WKqn1xbqm9K5VoWxBeosf37VYe2XPhBOWvgLE_8 fiz_1s6QVfIXh59wk1p9hTiZonyVmdUntD0KVxNY_Nr3wlCgx0cVxWo.4VYVaiglcNvj7SHqUzGK qNBTnYxwxen3BU6lMtBz4WYut6oi8WepiyW4Otb1E.JSFwe0r7N2hpUCWWJfmS68GJeclPUW4YEb 7FeCqjtQw6Hsl6aS993zZ85k_Wu0izCvlw2P3JWvpuPHPzCBNqomuykxHJi_NZ6eHyz9mZy2RKe2 18ZtvvioXnIpVeKBeolFHM5Ix3NPlZfcnEE0Li56b3z4j9YyUqshPQ86xFzMgh5ArxxcqIjB2maJ pCB_km9CmuuGvk2.RGxN4..6jQIdOl3xo9uKHQnjP9WJ0HpnczpUMiURbImfYrlJXwEbLwnReCzN rPR.cr_y5Bs51G8EFuLF5HotcjQoSemMp7T41wSRuF1Z5G6OtHgQT_rjm6rzaXQm_6gIbL1pI9aE wR9G7Ab2rltVoNWUdtWiEXJvGF_r8eNKoqQbljATqXjq1wUdGrkdyvPQGgh70feY4d2jzv_WHgto mnXor5br65QdvNw4b_XQu3qsFTXk3.hAY9qwRvhm2hZhrina266_fwNYmFGYOFb6xlbWl393D.ZS GPRfz7BUa5ueejXMwGEv5v2FJt7aWHYNAP5I84i5j33dYzDk6VbGtZLphYDAdRS0W7o8ESP6WIzI 3nqJaNNDtF4BYsr7__Y5f2PoP9lwOhSYv_bjIDKUKMIuIaLU4gyTdpvAfr87PGqypCb.jWuAd59j LQND3CISCo0V855rVPDLrlDU7R5tbqaksa3YvC5ulmho82j4KwsTdkVQNxEZ5Ptox.GGsgma.GFW WWlf5uNhG4vzTpCyVG4A_wpJTD_seZLs1PJ7XO5Aq07vaoqgMuu9eowe9l.B6LIxUjkfc9WqOFKq KgPU0kcj2iomDplq.bffOeobBVYqKbiIhOxUw6NFu63upf.t4PJnBy2e5P1N5VxfEvYOsyjMMYwF sNKLEGlwPw9WM4T9VWDI5tfwAcSbfx40r0NkyLe1upQSdsYKZQUI.MohNWwbnX0xCRTkPM63Y9Z4 dPHVQmuRWqqDpOzgRlqOVbvIrklzjbsHr6mQ2Fk.2rI5KMdNlgNaSNqsTbyiy X-Sonic-MF: X-Sonic-ID: 3650d316-5245-4679-a355-e17cc0527770 Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Mon, 11 Mar 2024 20:05:29 +0000 Received: by hermes--production-gq1-5c57879fdf-p26ct (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 4af4d8f39e2e28bdb00da98887d9c505; Mon, 11 Mar 2024 20:05:27 +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 13:05:16 -0700 References: <87B38D6C-1D83-4158-B03B-F4C8EA396DD1@yahoo.com> <4A386631-E8FF-4640-A927-46DE38F07F00@yahoo.com> <3680E93A-0E85-4E48-BE78-7B3C283AB399@yahoo.com> To: FreeBSD Mailing List In-Reply-To: <3680E93A-0E85-4E48-BE78-7B3C283AB399@yahoo.com> Message-Id: <9FBA55B5-D9AC-43AA-AD43-5CB40969F7D7@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.996]; 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.84: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.84:from] X-Rspamd-Queue-Id: 4Ttnnl44yjz52RM [I should have noted howthe processor frequency is heandled.] > On Mar 11, 2024, at 08:50, Mark Millard wrote: >=20 > [The armv7 poudriere bulk finished.] >=20 > On Mar 10, 2024, at 13:10, Mark Millard wrote: >=20 >> [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 >=20 > I'll note that I'd switched to using MAKE_JOB_NUMBER_LIMIT > and do not use MAKE_JOB_NUMBER any more. So: >=20 > MAKE_JOB_NUMBER_LIMIT=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 > Again, now: MAKE_JOB_NUMBER_LIMIT=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 >>> . . . >>>=20 >>>>>> tradeoff/mistuning notices are generated. aarch64 >>>>>> and amd64 allow more like RAM+SWAP=3D3.4*RAM before >=20 > I've not validated the 3.4 figure. It is likely a bit low. >=20 >>>>>> 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. >=20 > 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.) >=20 > In poudriere.conf I used the likes of: >=20 > PRIORITY_BOOST=3D"cmake-core llvm18 boost-libs gcc-arm-embedded" >=20 > 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. >=20 >> The poudriere bulk has finished llvm18 and rust, > . . . updating the related material: >=20 > It finished overall, in somewhat under 5.5 days. The "what > builds took over an hour" summary is: >=20 > [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 >>=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 >=20 > The MaxObs figures reported did not change. >=20 >> 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 >=20 > It competed just fine. >=20 In /etc/rc.conf I have: if [ "`sysctl -i -n hw.fdt.model`" =3D=3D "Xunlong Orange Pi Plus 2E" ]; = then=20 sysctl dev.cpu.0.freq=3D1008 > /dev/null fi In other words: a fixed 1GHz or so clock rate is used. It has heatsinks and a fan. =3D=3D=3D Mark Millard marklmi at yahoo.com