From nobody Wed Aug 16 07:30:46 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 4RQfv103JCz4qMHk for ; Wed, 16 Aug 2023 07:30:53 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 4RQfty48vnz3WSX for ; Wed, 16 Aug 2023 07:30:49 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of junchoon@dec.sakura.ne.jp has no SPF policy when checking 153.125.133.21) smtp.mailfrom=junchoon@dec.sakura.ne.jp; dmarc=none Received: from kalamity.joker.local (123-1-88-210.area1b.commufa.jp [123.1.88.210]) (authenticated bits=0) by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 37G7UkEk075255 for ; Wed, 16 Aug 2023 16:30:47 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Wed, 16 Aug 2023 16:30:46 +0900 From: Tomoaki AOKI To: freebsd-current@freebsd.org Subject: Re: www/chromium will not build on a host w/ 8 CPU and 16G mem Message-Id: <20230816163046.081be1181df386fae55065bc@dec.sakura.ne.jp> In-Reply-To: <2227F902-847E-4E50-B48A-B012CE51D96D@yahoo.com> References: <2227F902-847E-4E50-B48A-B012CE51D96D.ref@yahoo.com> <2227F902-847E-4E50-B48A-B012CE51D96D@yahoo.com> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.2) 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 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spamd-Result: default: False [0.56 / 15.00]; AUTH_NA(1.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.999]; NEURAL_SPAM_LONG(0.86)[0.863]; NEURAL_HAM_MEDIUM(-0.81)[-0.806]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; ONCE_RECEIVED(0.10)[]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; R_DKIM_NA(0.00)[]; HAS_ORG_HEADER(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; R_SPF_NA(0.00)[no SPF record]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; DMARC_NA(0.00)[sakura.ne.jp]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_VIA_SMTP_AUTH(0.00)[] X-Spamd-Bar: / X-Rspamd-Queue-Id: 4RQfty48vnz3WSX On Tue, 15 Aug 2023 23:19:37 -0700 Mark Millard wrote: > 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: > > > > 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 = 16582250496 (15814 MB) > > > > I have set swap to 4GB + 10GB + 10GB: > > > > # 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. > > > > Building the last outstanding port www/chromium in single job mode > > fails reproducible with a kernel message: > > > > 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= assignment to one of the 2 options eliminated the > issue. (No guarnatee of such here.) [There were 2 USE_TMPFS= > assignments, the 2nd "winning" --but the first had been > intended.] > > Are you defining ALLOW_MAKE_JOBS= ? If yes, are you using > /usr/local/etc/poudriere.d/make.conf (or the like) to assign > MAKE_JOBS_NUMBER= (or the like)? If yes, to what? Last I knew > the official port -> package builders use MAKE_JOBS_NUMBER=2 > for their activity with ALLOW_MAKE_JOBS in use. > > A similar point goes for if you are assigning > ALLOW_MAKE_JOBS_PACKAGES= . 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. > > === > Mark Millard > marklmi at yahoo.com Just a FYI: www/chromium built fine (stable/13, though) with poudriere. RAM is 32GB and 64GB single dedicated swap partition on SSD. Using ports-mgmt/poudriere-devel. No ccache used. In /usr/local/etc/poudriere.conf, USE_TMPFS=yes ALLOW_MAKE_JOBS=yes The line below is kept commented out. #TMPFS_LIMIT=8 On main (booted from different physical drive on the same PC), I don't use poudriere[-devel], but www/chromium (previous version) built fine using ports-mgmt/pkg_replace. The size of /tmp (swap-backed tmpfs) is not limited (means at maximum of 64GB). -- Tomoaki AOKI