From nobody Mon Aug 15 13:49:20 2022 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 4M5wcj4QLNz4Z1wj for ; Mon, 15 Aug 2022 13:49:25 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-24.consmr.mail.gq1.yahoo.com (sonic303-24.consmr.mail.gq1.yahoo.com [98.137.64.205]) (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 4M5wch2j71z3ZWn for ; Mon, 15 Aug 2022 13:49:24 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1660571363; bh=aj0SclFPzqZkc11uPhuH0aCu0UN95TxbeSnG6P2AAHM=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=jruwa5CIDdFqzNAtYX7iaQef24HyzkqiuzpI1IE43mwoe8ojoifnorWx541R7VRP52KmaJWXWtLeSjaIFCGOFEen2FxsIW4yhWqPWOIpKLzTazPx98zf9ifh9HiUYqHWIsHu0WLXp2rVASOekRy9WPDMD8ntf6B8R9yFtsKWN6hWZdacehU4Jeaj/hfjdnp5xXIcGf3wv/DXpQxv7uWm7LlbU9yzqYxicmhil6OS7QuRPsGQvhARn3oXi26lmAiHPOpTQKnIpFZ/q6Ni0DTfiVhkItkuqbad/gVoVD4ypKtevXp/k7ojYA3iTlWnLuHAl7tWGxDmRVBDKHWL/z5EFQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1660571363; bh=IIUx5KWklwudEUBMv/b3uBEZn/Dio3UZMrU937bALsU=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=pZY8xVrTebTbvHfcNUArQlBvAKGJYeztnYglQ4SmrwqriSB02/Vr1KiG2g+l5HoSjnn+StExcuBsGMEKI1Q0uoFiA7e4UcE8iDCQCoZzlFLdq1+WNY3BoGfLsiHeB7dIRAdZDjB5XMzbh72lzVmmKuvG4edIIeKnS4KX+yCGRGkvFkvXAoOs3OYLbbZcIcRPHmQOmAl2/Lyfh82C54KWIk1/I6/GZIlenITU17QhVHx7l8WwbENR74H3Q2qwjxk3oXu+PCQEEKvrfRtJBzOjyhIjW/NZFJNKZ3k5vEAVljuYcNe0OCTMh1ryx5as7ql9uhVSMYX/RK/HEQBKtDZ2fA== X-YMail-OSG: HRyLojUVM1l0MNA3CxJimkuNYcvNBGgumoD.vTmBzL0SvuE.XKrvmvcR4xt6HQQ huDsGbQWK99AQMRLCaD4LBLnov65AbsLG6tEDOjpzXko1nsq.1L17T85fOOxleVygUgfxhNClR._ abmqUNOwiQkAzaTHzrQ.xoHiK2CEJ7nVe6chKfrDyHfhyg3crWqkpZ5RoBpG8S_HRu293gGkdOQC ROl5BvdfbnrvO8DN7oJ_yTM3DUPaAS1m.nget6wBB0s1tOz0WfxBFvtRx9r336GNybWIf8e8Xz9D uI_m7mlLONn6b5_2NpGXcZL0bKQ7PFohLulSYUXBuOLvp6Bb7Xrm.so0PYa3xSXT3s9f3klhJoFL lwb_HTcJj1gqDU4wXv3OpIHgFsAV3FH.3UNkbpyHRlMkfQVADmG0DYqEvwl8lIfUFgWOyZQ7NQpr f.ZE7D7TJU8UsrTC73Mq0.zuLu77mbHcjFjl_urZSXZT2_gMQwTHc.hgEdOxBsBKZOElnQ.SeaEk I04wW8LChzfv_TAzAdesi7TMfJ9BaXrBKQOcYgdpsq3anMAR1kJtM4aMdqPmUv9aO34c4zmsjOXU ig3Fi.mAMGjnL6cPHZwyb24psmbkoK.OpsLgcRyqUD0j7OH2pI_D4KnISJuwnuDnRw74HI3KuccP g9szec1j71OJr.du66auL2rp_bbAlgqrISh0JKJCK72qXp_aBe8j.xHXcQrJY0IptuaVF4rXL14c jVxA2PHFb.NjoFpTsQCH79YU22.PmgEPznm8sum2oMvCVB1LBhQ4W_SogYSxWfZASpC56Pq5dbel iPdk7bi19kNwLqchZ9sVtTM2exKo5f4gh2yiZH.gRZsqsnVuN7NX2LUBZgzOzVIG_jrFvjpzfsjr Jrn3r1to55dJsDe4NhRXKYSkbRjx2rwL6vGcQQwuWCHNhDD8vgniHbtiUCzulUI5x2uNehWjV2AY 1TUuYBhgVbFwj7_uhbmkU1gBKBuzY.14xScN9iAzrY_hReBSGDtBUllDfh7_fYd3TJiYKJpnouCN F68qZxZmtVIxNjRGjPSPEg51TvkCofqJbOVhPCQ8ThKzJsc7rUwcqBT5Xb38d1qYDMSlLNC1ndkH 1FwjUHp_40uK_9eFa0jap0ilDU.Ofp6n4LRYJauDsKWokWISgVG8a0WItFIl8Qvyml_S7ZkXptRE aC0G1xDCE2IZDUL0.67OfxuyJL2M5fSLmVoB7DxlvhWTm3LDTmvaURa2UTTo.PFNjTflOi0XdjbE 5038JenlSeo0B0uTOgv4IaYTSoQFMdNMbNKEGK2bDVyr8w.FTqcWBww8tycINyMqlQ9F2zZLFw84 ksEmZ0x58BQYZdVNlqu1UBq7GgwBOAInkXuQff7dGeFRsHL8yMyOZuqsr0GqV7ns9IqZW58UAuxd xt1ezBQfGQNV7uNjw3C67L_Ll2FPVmgNyEY6kHxDd9ZsRWZ9QZUbRUiOpf7Ma7yhWoMlZvlLKpqN 7Yam6CM0l1pEiYUf6UHIUiYaHJs_aYFbasyxi6eiaUYrtkeXPpcIO0K.nGu0FwiEY4oceMzzfN8J OYIkcZc1b7KWC8D2hbUrETL.MF3gPQbCXCEMDHVaAfVkodVqoZBmKAF3_yeF.E0n11nVnec0HoiE RVS3dk0JyU51OuSo.FnMY9Wkaim4WsQR1xcDDw4F0oemBVyd0XnbA24eWsnU5f7QecwbDTwx6cel da4a3emZNJDrQTCSJiid29NNfoWplUIN6uEXsTERKh_PYvQ2LtdJAl1EYlmn68kCXyaFD8YTD.AJ hGY6jKUW9yWjqbWWhxnsnGQBRfDAQdZYsMpN1Ka6EApkYUKy_xxA.Bcejox_s_lbJ0ycuDCiw3gz gPjZXvTEl2zlSould.PzxX0hLO4wy4HOiQs4EZ0vhL5AAwRpq8j_O4fHKw5yPJCXWkf_4r1b2EE3 PSkaiidJNrbUeU_mfDnwWLSOTKS7JNGkbxYuT01DjG2ZSfzAHlDmcHBwr X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Mon, 15 Aug 2022 13:49:23 +0000 Received: by hermes--production-ne1-6649c47445-tp7sw (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID bbc244e2c918f1e64f923cc4ec40826f; Mon, 15 Aug 2022 13:49:21 +0000 (UTC) Content-Type: text/plain; charset=utf-8 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 14.0 \(3654.120.0.1.13\)) Subject: Re: Resolved: devel/llvm13 build: "ninja: build stopped: subcommand failed" From: Mark Millard In-Reply-To: Date: Mon, 15 Aug 2022 06:49:20 -0700 Cc: Tomoaki AOKI , FreeBSD Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: References: <1D4C14BD-8955-4B86-9C99-3E58D7603122.ref@yahoo.com> <1D4C14BD-8955-4B86-9C99-3E58D7603122@yahoo.com> <7CDC63F3-8B68-420E-8012-B1692667E293@yahoo.com> <21FC1F5E-240E-4A8C-A5D2-6B73494026C0@yahoo.com> <3E3F8980-8214-45E9-9530-D78243A29D41@yahoo.com> <20220815120616.0cb809413a551717cab3a2eb@dec.sakura.ne.jp> <4D8AB2F3-6A76-4E3A-9C44-348F1352A5D3@yahoo.com> To: Nuno Teixeira X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4M5wch2j71z3ZWn X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=jruwa5CI; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.205 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.22 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.992]; NEURAL_HAM_MEDIUM(-0.72)[-0.724]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MV_CASE(0.50)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.205:from]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MLMMJ_DEST(0.00)[freebsd-ports@freebsd.org] X-ThisMailContainsUnwantedMimeParts: N On 2022-Aug-15, at 06:05, Nuno Teixeira wrote: > Hi Mark, >=20 > I use TMPFS=3Dno That is the wrong notation. Quoting /usr/local/etc/poudriere.conf.sample = : QUOTE # Use tmpfs(5) # This can be a space-separated list of options: # wrkdir - Use tmpfs(5) for port building WRKDIRPREFIX # data - Use tmpfs(5) for poudriere cache/temp build data # localbase - Use tmpfs(5) for LOCALBASE (installing ports for = packaging/testing) # all - Run the entire build in memory, including builder jails. # yes - Enables tmpfs(5) for wrkdir and data # no - Disable use of tmpfs(5) # EXAMPLE: USE_TMPFS=3D"wrkdir data" USE_TMPFS=3Dyes END QUOTE Note: involving wrkdir uses a lot of tmpfs for some ports. So a correct notation in /usr/local/etc/poudriere.conf would be to replace the USE_TMPFS=3Dyes assignment with: USE_TMPFS=3Dno This might be why something is competing for RAM+SWAP such that you run out: You might have wrkdir involved via an implicit use of yes if you actualyl used the notation TMPFS=3Dno instead. While RAM+SWAP use is high (but not yet out of space), you can use a command like: # df -m | egrep "^(Filesystem|tmpfs) " Filesystem = 1M-blocks Used Avail Capacity Mounted on tmpfs = 1024 35 988 3% = /usr/local/poudriere/data/.m/main-CA72-bulk_a-default/ref/.p tmpfs = 31790 0 31790 0% = /usr/local/poudriere/data/.m/main-CA72-bulk_a-default/ref/var/db/ports tmpfs = 1024 0 1023 0% = /usr/local/poudriere/data/.m/main-CA72-bulk_a-default/01/.p to get a clue how much tmpfs is in use to see if it is large relative to your RAM+SWAP space. > and I don't have WITH_DEBUG set. Good. > I will test with MAKE_JOBS_NUMBER=3Dn in = /usr/local/etc/poudriere.d/make.conf and see what max n I can get it to = compile and observe used ram+swap. >=20 > Other possibility is to increase swap to <=3D60GB but I'd like to = avoid that because I will need to resize freebsd-zfs partition. > What you think about increasing swap? As I mentioned before, you can add SWAP without modifying your existing media by adding new media that has another freebsd-swap partition and can set up to have the old and new freebsd-swap partitions both be active at the same time, thereby increasing the total SWAP. So, for example, a USB3 NVMe SSD could be used to increase the SWAP space available. (You may well have other reasons to not want to do such a thing. But it is technically possible to do.) But, hopefully, you can find and fix why something extra is competing for your RAM+SWAP and so avoid needing more SWAP space. > Thanks >=20 > Mark Millard escreveu no dia segunda, 15/08/2022 = =C3=A0(s) 04:26: > On 2022-Aug-14, at 20:06, Tomoaki AOKI = wrote: >=20 > > On Sun, 14 Aug 2022 12:23:03 -0700 > > Mark Millard wrote: > >=20 > >> On 2022-Aug-14, at 11:07, Nuno Teixeira = wrote: > >>=20 > >>> I will follow = https://docs.freebsd.org/en/books/handbook/book/#disks-growing and = resize actual swap, but before that I will have to make sure that = backups are ok in case of something goes wrong. > >>>=20 > >>> I've tooked a note about total swap <=3D60GB > >>>=20 > >>> . . . > >>=20 > >>=20 > >> I forgot an important question relative to the resource use > >> for building devel/llvm13 and later: do you need/want the > >> fortran compiler? > >>=20 > >> If not, you can disable the options: FLANG MLIR > >> (building FLAG would require building MLIR) > >>=20 > >> Then the build will be far less memory intensive > >> and take less time. > >>=20 > >> It had slipped my mind that my builds have these 2 options > >> disabled. > >>=20 > >> =3D=3D=3D > >> Mark Millard > >> marklmi at yahoo.com > >=20 > > Is there any possibility that something alike Bug 264949 [1] for = gcc11 > > is happening? > >=20 > > For amd64, option GOLD (LTO support) is implied by default. > > If it causes LTO to be enabled for llvm13 build itself, and lld act = as > > linker of gcc11, small TMPDIR would overflow. > >=20 > > gcc11 required at minimum 5GiB of free space on TMPDIR. > > (4GiB was insufficient.) > >=20 > > [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D264949 > >=20 >=20 > Nuno had a specific problem others have not reported: >=20 > QUOTE > I've tested it but it still fails: > --- > pid 64502 (c++), jid 7, uid 65534, was killed: failed to reclaim = memory > swap_pager: out of swap space > --- > on a Lenovo Legion 5, 16GB RAM and 4GB swap. > END QUOTE >=20 > "was killed: failed to reclaim memory" and "swap_pager: out of swap > space" are not about "small TMPDIR overflow", at least not directly. >=20 > But if the tmpfs is of a form backed by RAM+SWAP, then the tmpfs > use can grow to contribute to causing reclaim problems and/or out of > swap space problems by competing for RAM+SWAP space. >=20 > Nuno reported having disabled such tmpfs use ( via USE_TMPFS=3Dno in > /usr/local/etc/poudriere.conf ). I do not know if that status is > well confirmed or not. I've also no clue if WITH_DEBUG=3D might be > in use. (WITH_DEBUG needs to not be in use unless huge resources are > available.) >=20 > My amd64 tests indicate that something beyond the compiles/links > themselves was using significant RAM+SWAP in Nuno's context. I've > no clue what. =3D=3D=3D Mark Millard marklmi at yahoo.com