From nobody Wed Aug 16 06:19:37 2023 X-Original-To: freebsd-current@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 4RQdK52kjkz4qHYt for ; Wed, 16 Aug 2023 06:19:53 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-8.consmr.mail.gq1.yahoo.com (sonic316-8.consmr.mail.gq1.yahoo.com [98.137.69.32]) (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 4RQdK40h4Jz3KGM for ; Wed, 16 Aug 2023 06:19:52 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=oxVj45sb; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1692166790; bh=8d/D5qddQBAkgwWf27a/JBW8msJU3+89TWCyJPMpy7U=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=oxVj45sb06vuj4eF2kB0yF/LUVznPPg7OZt2ETVLGV/FvpTdXS7Pl0P/60BGokWUziV4VE77yoDvW/dL40ef+M+qk8cXfKJpqYgv8jRDL+iL6s19S+ij8IPzKOKK8gteMDnrwhGUxiGV42R8g/N2OO3P8e2+YxFYM7nhcVD2EDicP5VPHHf1DSBrL5zir3LxYNmnO/wufLMeRda523v7m6qhenatbH+/lquUTUHfxmU7TllcnYZtXD8px2++ZJrkQfxoWYu1RbSra1kk3NrIWXpevRPz72HOfqAXPpm53U6zN4Z36/lDYDyHcgPm/ogNixOTH9HPurZcTHndJbzh4w== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1692166790; bh=+JNhxUmGvrVL5WIltrjQqzXQQekfFJCNJz/wAqkzDSi=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=KCqqekREZLZogaHi6ve3GE47S5vfXNt+cK2PHl3FzAqKzQEEtgvdC5122KgjqFmRLSf6fezCjYthWkRfqP1QHRW8jwI9iACxph3IAJmsGIHgNTSe6niXf2vI36AqKhnwtZtngxB+gGKADhJHrDa2ALDTdhmO1/KK6KYC7SJglFCzL3tMOeE0AAKlv41/O1DVNxWWCMSa5fzDWSP7nTaG2JpWLWJlPLuE0EWF2eKiWAPJBN7obGpMB1PKLdqgb7hx1tRF2LGGCIqrrZgyJZ3oXYoZ0E6J3KcZHwRNpKzoVdP/od6aEqGYUduH69mdOyYrZDrpBxdag1SQ4+9OULBYUQ== X-YMail-OSG: GVNDgtgVM1lujNnpkgOcQvB9BGbBHgE52MozTlTL5.cXVzOXCUp32UI7TsQsrqi pe0e.v8WolR9CY7Xzj..mkeXewrxzK24UOwKrnWCZW.cdmDPjCWxL0sDVmbCLX1o5uA4DxIDK0S4 Q.2w2myoo4Q0ekdtUu_ExFpOHbHSrHmZTKka1GGvGPk2EEU1PUH.wa67RGoV_ArHX2.JFEyVeCHo DYzqmd.QQUsZDA7G_P4GeWGBSaMib45h19dJQx.34TE5s9Mfi5lnAhdhbOwdENkQ72bk6JuoZjmi szG66r_cFiqisSJN6IzJ9LcoAkLE746vsxr4M.p_gDdKWgeZKu11nm.8OPThLyQ_LG4TlUWH.zBH bPz.f_0YmoUC9MatMgbNS3ljfqKbrC9243DzVRrPI_CzVEI5nWOwjtBnd7QApNhn5jp6InDQFegi gSUJpgO7mODxE5S7e5O36hrkPF3p_YxB03oEQeEC1urltwbdyDcqFUwaatgx.GcA2R0sgwe.MYT5 MTXPe3IqZWCMq9fVBf9rHHUXPNg4NTsszA85b12Ssj2JTo4xyBA7O2pep5WwvLlYgT6XtHgmrMMI 7BnQOKbkZyWkkPVrDj3iac5OqFm7BqQe7U7LwcgNm7WOr4jy7AUSywp9.PWeX2OM5d8aBszf7yXk UmiAuavFN0HABLQ6jqsHmJPGfaUJtipahAtaZfvJjtrtnYA4ytGp6JojyXF.orHNEZmoh6G.VcIF 1uWGpsCf9.cPK9na4XWMy5luP7pr787rbBGYWAtzsVG5rAVygJGhusa.tIpNBg8ICMtRlkqhgWG8 KeK63DcSMAmeHgwXMLiQgtAe9RX5Kma6DGbWGyKexyYV8OG5XNiRBXJRIC8P62YlYhW3lErS_GH2 P.wp5l6Oqghj.YognxKHRekfdONM4DUs4XKcYl8F0cUuNDCPkHb6yB5GcB47wYyZp4kCnpoAtxlH sh5diWfLUKSotiEPTcxQaBBnFQz6I9s3SzV47QD25PFnrApT6Z5qFhc5DxBdEmGlVtQ74i83WcxJ BmwkVLIYwRShws.uMGCRxUCBmF3XV8jMbvAm5nFrP6VXjOhWfuwUpy_O_LuoWao9w6VEa6UZfcxd FFDFZLpNc0MPHnyyJnvnfamGaFueQbsBaOc.jZKHiV32iZiUDLVB0TPtTH501DB8Cm00WHgS6JAC x8IaL2XChpakvndRKC8V45dB_S7.0f79974r5Kwb0LKmrwRxGFjC8lIJ9kXFxNF.4LCQGoxfwc0n TL29Qhj1S.4t1CwzbDZR5ZXajwfbNeFpfSdRDaDVUz2DhmN2L9zw5GfkMZ0P3u2WvtoD_42Dg3Gq UWEgM0m68tVWE_vCD3yhF6LbQLc_U7E6M1eUoTUY1MGdAxt6xQZAhiwuQRDWNWnoXsKUkuLp4sMr djPgnyQ09Bu3AbBwTHbiTORvhAWClIBm66pKX8v1vZUeqSrbOBsoh7ty.tYVF3qmyWg09cdsO7ek 8pVkeO80kJUEzoxs9nUtn9HIQantZ2Z5hFn8H2fBql9biGjngklc5psqsIMX_mZ6lhdqCfALF6nk XbyRl.DAnvLQcTCTpFcSLm07Vuur5uIrtPGGaMfYaAaW67w93vwIjbCuAk.NkKEG03UglIsWDxeK TzNNfeXFqCz.vnpIbH1Ya2d4a7YdBhulfpCky2NbpYMHNyD1PwdEZJ3rCY4qKKjvAV48ZBhLDwKI xgL9T9BwbGDz8kZH2C3k2U7YS.LWjF1NBkVfsc3ibIU_zwA1L2izleQs._xnykXV2.4.c7i1WnIL i..AON8Nwv8uD4wDh3bLn7zGxnFpniXIcbW6jx0NzxTkSav_kn9UXarLy3vYfd9KdXfuEy9YlDdX N0whj65O20P3wCFcKttlrsj9mpozVyKHXkfXMpLpxRtQ4bNpvnz6X8kT8wQrz1NqhMPVvYK1ZudS C0IlGYzpGf3JRo92ZsGezY5gRLga1IR8rZxqUnJ5XJOI9pqEFItAwO73c3teJ93NFtAlxAjEArBo LxFfckyP07NpVQkCYpjs4YI9gbHRMeF6NeIfMpK.mZTtoDczewm2Lf.eE69X1gTM4d9CSHX9ILni 2xa6yDhkbKkS_claC_c0xGCd0zF6gkYAKqchmHDDzhWaRRjp2zEartQOLzxB1sduKV2qMKAIbsJi WaaTQRPZOQ9rDFihlqc7d6dAppcTzMUDS_foGa8TEbDyjy.Iqz94H7bIcEsWRCUnKzexTvvK4eL3 CNjAxiwcpG7MKsDVCgGhVgpM6xApqvgLtx2Jdp8iZb4p1gDuJJsBb6GrwhxAGN0JZRnt7SxxLbrQ - X-Sonic-MF: X-Sonic-ID: 73a434c9-ed15-4eab-b165-cfeead51ae14 Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Wed, 16 Aug 2023 06:19:50 +0000 Received: by hermes--production-gq1-6b7c87dcf5-m4lb7 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID e9ac675689b03a331828f6f9d9aa649c; Wed, 16 Aug 2023 06:19:48 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\)) Subject: Re: www/chromium will not build on a host w/ 8 CPU and 16G mem Message-Id: <2227F902-847E-4E50-B48A-B012CE51D96D@yahoo.com> Date: Tue, 15 Aug 2023 23:19:37 -0700 To: guru@unixarea.de, Current FreeBSD X-Mailer: Apple Mail (2.3731.700.6) References: <2227F902-847E-4E50-B48A-B012CE51D96D.ref@yahoo.com> X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; 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]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; ARC_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.32:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.32:from]; DKIM_TRACE(0.00)[yahoo.com:+]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_DN_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2] X-Spamd-Bar: --- X-Rspamd-Queue-Id: 4RQdK40h4Jz3KGM Matthias Apitz wrote on Date: Wed, 16 Aug 2023 04:31:38 UTC : > I have built ~2200 ports successful on my build server, which is a > Dell R210 with 8x 3.30GHz CPU and 15.8 GB memory: >=20 > Aug 11 19:03:21 jet kernel: CPU: Intel(R) Xeon(R) CPU E3-1230 V2 @ = 3.30GHz (3292.74-MHz K8-class CPU) > Aug 11 19:03:21 jet kernel: FreeBSD/SMP: Multiprocessor System = Detected: 8 CPUs > Aug 11 19:03:21 jet kernel: avail memory =3D 16582250496 (15814 MB) >=20 > I have set swap to 4GB + 10GB + 10GB: >=20 > # swapctl -lh > Device: Bytes Used: > /dev/da0p3 4.0G 1.5G > /dev/md9 10G 1.5G > /dev/md10 10G 1.5G Are those /dev/md* vnode backed? If not, what type are they? FYI: On 2017-Feb-13, at 7:20 PM, Konstantin Belousov wrote on the freebsd-arm list: QUOTE . . . swapfile write requires the write request to come through the filesystem write path, which might require the filesystem to allocate more memory and read some data. E.g. it is known that any ZFS write request allocates memory, and that write request on large UFS file might require allocating and reading an indirect block buffer to find the block number of the written block, if the indirect block was not yet read. As result, swapfile swapping is more prone to the trivial and = unavoidable deadlocks where the pagedaemon thread, which produces free memory, needs more free memory to make a progress. Swap write on the raw partition = over simple partitioning scheme directly over HBA are usually safe, while = e.g. zfs over geli over umass is the worst construction. END QUOTE Use of swap partitions is to be recommended to minimize the chance of paging related deadlocks. You have not reported on how much swap was in use shortly before the "was killed: a thread waited too long to allocate a page" notice. (After the notice is too late of a time frame to be of interest.) > and poudriere does use ZFS. >=20 > Building the last outstanding port www/chromium in single job mode > fails reproducible with a kernel message: >=20 > Aug 16 06:14:04 jet kernel: pid 48725 (ninja), jid 3, uid 65534, was = killed: > a thread waited too long to allocate a page You have not been explicit about how you have managed RAM+SWAP tradeoffs in /usr/local/etc/poudriere.conf settings. In /usr/local/etc/poudriere.conf : what are you using as the USE_TMPFS value: # 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) Only 2 of the options keep the tmpfs use small: data no For example, building rust can use 10 GiBytes+ of just tmpfs space that competes for RAM+SWAP. The last personal I helped that was getting "a thread waited too long to allocate a page" it turned out that changing the USE_TMPFS=3D assignment to one of the 2 options eliminated the issue. (No guarnatee of such here.) [There were 2 USE_TMPFS=3D assignments, the 2nd "winning" --but the first had been intended.] Are you defining ALLOW_MAKE_JOBS=3D ? If yes, are you using /usr/local/etc/poudriere.d/make.conf (or the like) to assign MAKE_JOBS_NUMBER=3D (or the like)? If yes, to what? Last I knew the official port -> package builders use MAKE_JOBS_NUMBER=3D2 for their activity with ALLOW_MAKE_JOBS in use. A similar point goes for if you are assigning ALLOW_MAKE_JOBS_PACKAGES=3D . Are you? These can contribute to RAM+SWAP usage and higher load averages. > What could I do in the port's options or kernel values? I've not actually gone in either of those directions above. But nothing at this point says if I've happened to cover your case vs. not. =3D=3D=3D Mark Millard marklmi at yahoo.com