From nobody Tue May 17 19:40:32 2022 X-Original-To: freebsd-hackers@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 4BD221AD8A95 for ; Tue, 17 May 2022 19:40:46 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-54.consmr.mail.gq1.yahoo.com (sonic316-54.consmr.mail.gq1.yahoo.com [98.137.69.30]) (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 4L2mgd2BFbz4Smt for ; Tue, 17 May 2022 19:40:45 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1652816437; bh=4jNYqonb0Vc1JpEnXtfOuC2lQSyk5zsKNQmZcTOO/M4=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=NPP5sYXTNJLU2VSHfzBKALy6femzj6vaLfHW7WcguzX5ElyjSb2ivVy32wsKQG9bgNKpITN/MWlyBxXBhvGLztBazYiUeE+1edaRQbfbdlPTZubZZRPvkguMB50/hHDOZtL7YLoVVEmQNPocMH+DviVnEBJR44iCktI52YJ4WviiXtHittMBSO7G0aRh077v/RAj8eFknJbxCTItXGAQRLBNGk2zp2+L9ly1IZwgzTYjDJEwacrT7S9vNPFjh3vRIc273JumQINYe9SjZwhjJ9rnZn3MfkM7o9YKaWSAYmcUoL0YEueRjW5/EQU24esPbdKCJGuX4Sao5mhMjtrDbQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1652816437; bh=T9kect9lEfRqKHzoEp5FRUd43WmqmDITYpvX6bPsZQZ=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=pmNBntomv1L6ngu1B1Vgb9D7y5s2yuC52zrMLe27skqC7s8oowMG/1ksOaNuvKf1J/NekR75AoNwozgavt+NAiM1q0IrO4Y63eC4FkukCrBqZs9/2pxCKoPglk2hPdQpdiOpBLywz0WVwHuY0ibhONLCsyDD4C27M6FiflY6xM9QclDadXH+/URVrk5R85GlTATjekIm+7tq0L/iZatWcROGd9T5nqmwiAjP9+LYh2tmUmXKID90rEHKmo6UigSeZPzkwHHJi0sin7hA76QyywLkGMaX5EdpE3mSLRAbmlGCAvu/qGlpdHVnGdnXSxu12FqlYdXWVNtp+GAOgmqTYA== X-YMail-OSG: Yn5Zev4VM1nt9xNKbWozbDZkT0S_t_9tZR0WP6261EgsHv.NI1QSMZPnraF510O AGnTBI2BnufWszpFWVKYKLZ.PcSDCidIL21zMqQoEBJaXEqf1JMyUMmSpcBLuudUeT3jI1ZW5WTm NMcYsQZRjsFdsFRZs2cWQUsumHedfjde5bMNxYrYpaF5ixL.O0oxBgNFnbZ3UBt6gkVCNO_rJ.mm IiSyaC7WhmYxSA706RVQYpraMcTH5Dwb3Uk4GWHhObN55ycUkH0_vHKRHaaEMdmPt57JfLrnwiq8 SocVk32PErsaozyfkRZNPqp86SLwSeE_zRCOgBsttk5XgI.8vpBVE8mPMyMdSRhjfWPQQ5RYmJvv x_5zwI4nORZEV1VzWgt42EJSEl3i5tbrXeZsRMDJFVdUMwzSjpA8NTEkaHvYB6J30ba9ebiA3Vcy NuJYUtSL3WyMbYQrb9W6EB7qk2ThMN3ybJoRIAdxYEJ.eZqLZWYPxg24krEIpa1C3JCiQXIN0LV8 .gnTJjsxH4S2q.0SQUdlIc_Z9vnwssAVMbS0vbbpU_U3Xg81m4EOSMwhlsVWwZhyJ4m1ZoHWz3Fg 5sH0CqwFM5bCSjYdMjGJgK36rJcwObkLO0U2P8yebNelAVDvHN75NvQCbpD.V14NHvH4QLDpDquQ jnglNPvl.yhYBlGm2078Dmn1rNJ70MzMkfuO1PfaOKZS9BmGpdeXJKNd49Qz__k1ugKTvS7Fd_j_ l2Nv3tbI6orPCpbPESrH529b9Chn3YkeMHEOQEkqdtzja1059cotERuaZ.l1IuMfXJT7o71AaylM srqu8IEGtrA52nA9MLnAXUWHej21NhVFetzPiFBrRAqzhfgfW9Ek4KHOgXrUI7Q7Shz1x6zp.Eh3 LhoppeNfdKxeeskAgrSJlZ_EnfhqefysL0.TT.4UrQvIwBvX4KOo7ZdK9goh8lpnXI6PE1wNZ0yA AC4l_47BmNjk1Hl6yuVLO.ZcCPNiaUybyE9cLatNZH8O7YR7Pltl_FoprMq5P7jFUcqDWcJvmIeJ nRD3KKW2xCEqm3hA6iTVmotyktZ7s2CRaCKrE8n.kjbz62oSWbfH6Ni5v8FUjrriFLyQnZCtRWNx Yq20jFdqveFYY3BCe.d2nKz_IObSVUMszYgrmcL2tJZrKR7uLmwIzprhE4M8TjM6HVgLbVmNw2_i T1aMuxG72LushEQ.xfEqqhlAax5V.8BlZEiGufSeGP8KlVeF2wAEbLQRHPzyD2zu80_kZn5cJ8SD B_z8pub0g2b3a_bg6_KrIFbfcs4XJe6zZDIrMhfjoch9Q5wyWZrARlUTXg0pP.KdiECR0EizIQ9J GULz_HBlkNosfLom_Mb1Qu6aFqncBclXCDYyt04H7MGs_wXaXEPc.kG2vcaoY1g4kSsY8J9bY1Cs G4HJP1SjWSjSqQEljr.ctsyqx_btaamhRFzzc_laKjhl4EVq7t8vrpigYbGqoqvz.ABVm3IDaGwX q65UloAJpuSYG1ulSQzrBDBkhJ9RyQR2PWmBOYP_S4wJ7jwqYZqSZSUbF_kwpfp1bAP0UuKfh_mG ipY0TFuvcEJotwNESg9hpUsDgCDUZNNY1IOEyF9_P8p8rDDk5xynkyyClBoSy6UFyuAyxF23e2k5 ZWpbAX9vofjSFBjPrfgA.0f.G49lfctfxJidfFVhehS5.IpSa.cLLLsy1CAoS3RRxCqoaU6VBds5 y2KwHpY.yNLWAdsNdDCX.QXDJr2d2ppsfQpdfv_fS9NkkrbG9GlosDcsiIrstqXutcM5gJ60zKMo hus7KLpbKWto07QIZRQN3a6Iz8EpVvvBeDCaVmyP_JNiNhVRxGE_415jd.E8HFvtwTWrMDvKqAbd XZkS55vjJ4wxGQbF7EOPeb1JAsRsiolYobJht7tpBX2.qOnzeH_Zdg2VPKYTHqymq2dyCzK.3AfU 45Wp31QlY1DPsNKYXErKma0u4WzK1uUrpF2megvSz7ZdvAaKgWmJA9Vg24kZxXWe8RGVZiBXiLp1 ZOZLVPy7CPOizSOnwq1VBxEhl1K9m49l4tqqXQaiS2c6V5eMJ7bMo3dxIZBV0H.X1CoPdFY4lsxv 3QCKxkWwRfrs1l3Xu8CiCiSBXFmFUMFWYqsnQ7iwD96o18LToMrDqe57fPfA0DUU66Xq6L3.Ee4N M956UmAbRdifRokUYStryHuKXTyaR3nLj61nUUNoEvBCbz3_foRd_M.1MyYgDAxR2EcCWuyjlIMd 1.PbOSGqw8QM_ZJnn6niax9dhbCY2Glv6.Ax6EGcPLU4GMwZ88FmyhVHF4CX2Pa7veHDCXPnhLXe .i8oxD5G1Fg-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Tue, 17 May 2022 19:40:37 +0000 Received: by hermes--canary-production-gq1-555f44848f-4dqql (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 184b8f71ff04371989f8cfbc67d84514; Tue, 17 May 2022 19:40:33 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: Can not build kernel on 1GB VM From: Mark Millard In-Reply-To: <20220517135616.GA72471@post.wayne47.com> Date: Tue, 17 May 2022 12:40:32 -0700 Cc: FreeBSD Hackers Content-Transfer-Encoding: quoted-printable Message-Id: <2892AE2A-E453-460F-A243-0E98E5DF3C8C@yahoo.com> References: <27171A11-13B1-48A8-AF46-605091E1093F.ref@yahoo.com> <27171A11-13B1-48A8-AF46-605091E1093F@yahoo.com> <20220516143753.GY72471@post.wayne47.com> <934C3159-4B1A-4A2F-9C21-93DC7CC90A72@yahoo.com> <20220517135616.GA72471@post.wayne47.com> To: Michael Wayne X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4L2mgd2BFbz4Smt X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=NPP5sYXT; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.30 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.30:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-ThisMailContainsUnwantedMimeParts: N On 2022-May-17, at 06:56, Michael Wayne wrote: > On Mon, May 16, 2022 at 12:07:18PM -0700, Mark Millard wrote: >> On 2022-May-16, at 07:37, Michael Wayne = wrote: >>=20 >>> More info. I am running UFS so the ZFS should not be an issue >>>=20 >>> % pstat -s >>> Device 1K-blocks Used Avail Capacity >>> /dev/md99 1048576 0 1048576 0% >>=20 >> That may well explain some (or all?) of what is going on: >> file-system/vnode backed swap spaces are subject to deadlocks. >=20 >=20 >> Which suggested patch(s)? Any patches for . . . >=20 > This one line change (patch reduced to only relevant info) that > was posted earlier on the list. > --- a/sys/vm/vm_pageout.c > +++ b/sys/vm/vm_pageout.c > @@ -1069,7 +1069,7 @@ vm_pageout_laundry_worker(void *arg) > - if (target =3D=3D 0 && ndirty * isqrt(howmany(nfreed = + 1, > + if (target =3D=3D 0 && ndirty * = isqrt(howmany(nfreed, Why my brain was stuck on "patches for messaging better" I do not know. Seems obvious now that you show it. Sorry for the noise. >> Can you switch to using a swap partition instead of >> file-system/vnode backed swap space? >=20 > AFAICT, this would require a reinstall as there's no easy way to=20 > shrink the existing image.=20 You may ultimately have a requirement that the image containing the UFS file system and swap space be no more than some specific size), implying that the UFS file system would need to shrink to make room. But, for testing, could a copy of the image file for the VM be made and then be grown larger and then a freebsd-swap partition added in it for use as a swap space? Then: switch to using the partition to see what happens? At least we might learn if the issue by itself is sufficient to avoid the problem you are having. 18.3 "Resizing and Growing Disks" in: https://docs.freebsd.org/en/books/handbook/disks/ has notes some notes about doing such growing and mentions virtual machines --but uses an ada0 example. It includes adding a swap partition. It may be best for such a test to have a larger than intended swap space as an initial test and then, if things work, to change the swap partition to be smaller and see if it still works, possibly bisecting to find what an approximate minimum size is and then judging what to use from that. (Either way, relative to avoid the existing problem that you are having, based on my experiences, I would never recommend file-system/vnode based swap spaces be used.) > Summary of events to date: > - This was installed as a lightweight machine. It will never hit swap = in > "normal" operation. The toolchain's memory use has been growing as the versions progress. Fixed RAM+SWAP sizes over long periods of time are not realistic as stands --unless room was provided for growth up front. Because of kernel data structure tradeoffs, SWAP sizing is effectively constrained by RAM size. For 64-bit contexts, something like 3.8*RAM avoids notices of mistuning when the swap is added. (An unfortunate property of the mistuning-message is it makes a suggestion that involves other tradeoffs for other kernel resources as I understand --without giving any hint that such a tradeoff is involved.) > - The only reason I added a swap file was that someplace in 11.x = building > the kernel ran out of memory. Toolchain again, yep. > - I only build a custom kernel to get options TCP_SIGNATURE for bird. Any chance that you could build the kernel outside the specific VM (in a less constrained context) and somehow transfer it into the VM? > - The swap file worked correctly for all of 11.x until I tried to = build 12.x. file-system/vnode backed swap spaces do not fail on every use but are unreliable. Back when I was isolating the failures that I was seeing, I found notes from a wide range of time frames from folks having problems, as I remember. (Not that I could point you at them any more.) The problem did not seem to be new, predating 11 for sure. The toolchain memory usage growth over time has probably lead to reaching failure for file-system backed swap spaces ever more often over time for ever less constrained contexts. > - There likely out to be a FAQ or handbook page about how to lay > out lightweight machines. Having used it since 4.x, 1 GB "seems" like > a pretty big machine, yet these issues arose. If partition based swap spaces prove insufficient, it may require adding messaging to the kernel that reports on just which of the 4 conditions is leading to the kills --and possibly related information for the one that is happening. That context might be required to make progress. =3D=3D=3D Mark Millard marklmi at yahoo.com