From nobody Sat Apr 16 01:05:26 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 052E68D4F5A for ; Sat, 16 Apr 2022 01:05:35 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-20.consmr.mail.gq1.yahoo.com (sonic314-20.consmr.mail.gq1.yahoo.com [98.137.69.83]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KgFPB0VvWz4Xpf for ; Sat, 16 Apr 2022 01:05:33 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1650071132; bh=CfuwSsDACFA1pMIv3brKK7XNNcktLvtF7N0z3eL66xs=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=IE+S/y3lhi4EbKSpFvhbUvzKsGtBcUggQiAV6HpITHEvdiqYgfC/jViytBqWF2nnvHxlXQgYw7M6dXei+PcWL9cEqVNprTcNlAbljc6P3+jxtpaxXs4mFxl+mLH34xOkHwDzQg34n5g++a7bVLOMYR5K0w5lgBM3p7MGsCMnIdEhwGVV0zfOonsAM1zYNG0VJcN8l3EyVjlhzObs8QooURDiENUmRK/GxSIATvYdctJN1qReFDDFyHWRaLoZO6uufh2ai1gRshbrmbAQYB9n9NvozT5BZ5vL5sOtX6sA6kjGmDlukRAbN8sn7tRVfHB5HXdjk+VarWTvK5AJRYUbIg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1650071132; bh=/oLDgvUNYWV/9IFXtzH7QQaV2iNxQ4dHB/zWOAap7j5=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=jPYz1GAVtSRRT/qh92qroC5sno7WYAxV/zWh5voTK7RzNbN/r/MPyfP6Kz4veM+LJmQnJdDPJS2hoxPMAUdIOGkScbNUns8m2Vbewi7LO+MNfHMxpD/rlbN6yINEFYvcsrbBFlgFIuxU9J3VTlSMCDPRfCRaOVa7bFZYAIsqetfgoq2b2Z1OLbnKX3ncS1DIP4gY2nhqAR+o/ZXT/7tI6glP9uB54opWE1XqkFH5ZvRazGAkyENzQ0KootvjY1GUeVUQh9g3SdOfMxkQACzdewb9xwFm6TqowuTNAKmRMTlC/AJzPQJDQDJjGIis4tBtDHlu+lhMsHNodkgOZhVYDQ== X-YMail-OSG: iOEbbfYVM1leXsYFh6BekKDKrG4MJJfCw_sfYdSjB_Pkdb8pdd1VEYpjW0plQ9C wIf0Iet5jR99leY4IjWNqpmToo8dqomcsYEBdpdoUeWDb1NwJAOJpLp9h_92oqDterINrqWGIstt .NyaFMkJs2D4bqsVpNEd.As7PtwVJPfcg4iE_T.kifncs9tNRQSRAxlrN6S4riRwCPQ5Klaam3f2 u8353tTc593hyi55MW6GOIYiJLAC5F1TlqF.xB0x0uKKRfhIuLg4uFKfjxp.lIGLBNabdcdVYg5s MUhn2JqS6CuX6mR4yLJ2INhtH7iSUd9PyyBCtRZOAj0O5qh1KWBber1cBv1VuxPHOxMUWnZEIllT nH7u9Z2uQ83tdgginAOOCfD7kLtxjRtDpeoxc3RsEmScDtgsaQZerkU8r7kKF5RCWCI9lsG9Xrwc JvPIChLX8XvLxsH0gJq7ruMmNYDEw2P4YUsgn7usIDPoEM99ke7nvFnsiI_dzUutHph.6H9fUjDd ySyj2gHXWLdD4DJYvC.FoVA8bHs062VlPTLHwuBQQt2tlHWGxrIcTACTgFttpSpFHECDIUtp3jx0 pmkWBmK619mC2K1roaefcDqfmcg_aGO1kLVIQ6CQSP_4AF5MddZo2lEokn1M9eo39b01alCyUPUg BefiSXDkpeCi6g2kQnS7eTxl2srFT86Hoc7M8wiwx0ZXn4jAG4hQi438xSoPxfrDd1FSMCSucvOR UjHLYmbYxpgnnruvTi0X8MGL23rjAnA946bdbzavB6uV4zosSCKup5LsstO2qjE4HWqmjUSm0jVw Wdlq8TOBz_POMk_1IMMggBO6FhM70tcHdTHjAutskCmE.X00dMCbKfycBlr2Zd3jYi5bCmXUffYc cyCgWzXIsQf.P0qBmrOQU58wK1gOblRWtquLadr1GnhYFs8iiGdzjjPzxRW7qhG2bn3JEudC2rAq pAE36PwQgY4x1_ommLQtq7Y2Q4adzo2I7A91q3VLnyCmLMP9.KwK6pd8GdC68MxDM1a6Sop3xqta zWjfu7S195xpDVva3h5oCVwQjqGS81E7TreUGR4XGZMGlxO6_tgySFN_I3KIs0XPnxhXZeBDZZ9k dP8fXbuqr3QGjLN6woqDniZEQdxH3n65CDwM9Ec0Dvc2JZIrSsHGoZZLM4mXOYtmMlAibal5jhP0 GJrVHWaTVgwBRAItPLNbdZy3HS5Txdy7dnQVI0fDTks2nvlQa.QjSZ.Du2SP5K2eG_hsYj8tL_C2 BfQ0bYy4qTcDogtLHlU4vCeCap6qRyWNNfjM.ZuBjZcP1wPQ8wyTcxPgiUZmPdXg.QalYcxHci9K V790AJHc9_zOPt0bJRVA.7K6m0XZsZZnk8NuhOvkpbUTxsSfvcrDL8b4hEFyp7Z7BGTGbnzMXImq DPSSvVJagnRtVvz71LNzytCdoS6_4rOdnp44unr0N.51HCFdqL4cl5s5hGYxMXCZvsOvUb0ELfRs yQFpEDc.OIiQnzSBMsTSRHxlI7hD_jberYYckGJvxrMgsEQzuPBhMasXZi4lbvmTATArChwP3yxg Wm9VTbE8q30LhRR8Rb_oPgvKI1Gu6lsCR4wGfrmxOhoa8b6gGIOs.nfXOSBZCG4EkPiT.id.sthn 7sib.uEYbLiyCXss4.HwcdIgCFevTl9SO0r3DWpQ3Bs83k7aMrL2VxvtEIaT9ShF0Uk3cHUpIYKd 777N.2iaXIwL7fx8GdEc0Gnorh0IBl1IJ_yVIucCDrD02QjAnFU2xFJbzQOr7v7iEX_mN5SoKKgX mPzCHhy0NrTBSuINRex4UdJlI96wwKMufgyKhbltF.iapsbd0es0x9el.I.ytjFFY7FIOts7VlUo ONzEOuDcSqna09SpvOJAjnfo2KcudxtEGmCtQQvERNQO_wlybZ6EgHJyvAtaxOMC4T.6d7nWINFl els0tt5Fl3j1gQeOymNqC2HKmBMSr.R6Edg5QjmagvbeU8US53BUncgLEYoZn_0rvtz..ED6FAHs yRfZmsudumewDPkOS2gGzHxs6eg_wVSJ2JkdtKhT9x3B2M3dW4VX28MB_gskTQpSVLRdHXwRQkJG hQYXv2giNEGfjrJNMXQM_FBNcCyyod2GBINQTa7uyWd45xp8Sr.bge3h93k0Vq7R4Wnaoqn65XjQ y2cr4DnBaxDQ0ElRQKUxqEXkKUf6ofq0nJmc9lxZ3hHjIN357Hsnxkd2xPYa6Eqa3t8_J2R66A.j AXEGjTi7WODhh9xLwiB2KU3x2VExe7nJcIDSYSKVGoduI9jabRuBWrk.GaVm2xrPkC3Xuxwwv2gr GOjXzdk5HcqsT0A2KwfnFHv7z73isrFeCkLq2DMBvvPizzF2laARHDaWA6qU9nOf76Wt5dYPPtRN GFLNJufrZhWn4 X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Sat, 16 Apr 2022 01:05:32 +0000 Received: by hermes--canary-production-gq1-665697845d-jhlhx (VZM Hermes SMTP Server) with ESMTPA ID 3c364aa18fd11a98d7f5eee8fabc47c4; Sat, 16 Apr 2022 01:05:27 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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 Date: Fri, 15 Apr 2022 18:05:26 -0700 References: <64D7342D-A0FA-4E05-B883-CCEC6DA79515@yahoo.com> To: freebsd07@wayne47.com, FreeBSD Hackers In-Reply-To: <64D7342D-A0FA-4E05-B883-CCEC6DA79515@yahoo.com> Message-Id: <61D59FF2-D8E5-417D-BA49-6E4A91D0C7D0@yahoo.com> X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4KgFPB0VvWz4Xpf X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b="IE+S/y3l"; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(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]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.83:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.83:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N [Dropped Mark J. form CC list.] On 2022-Apr-15, at 15:41, Mark Millard wrote: > From: Michael Wayne =20 > Date: Fri, 15 Apr 2022 15:17:43 -0400 : >=20 >> On Fri, Apr 15, 2022 at 11:40:02AM -0700, Mark Millard wrote: >>> From: Michael Wayne =20 >>> Date: Fri, 15 Apr 2022 13:49:53 -0400 : >>>=20 >>>> I'm trying to upgrade the machine to 12.3 and having swap failures. >>=20 >> I reduced the swapspace back to 1 GB. It's only ever really hit = during=20 >> builds. >>=20 >> I set >> vm.pageout_oom_seq=3D120 >> vm.pfault_oom_attempts=3D-1 >>=20 >> There was no improvement. I still see processes getting killed due >> to no swap space despite only 7-8 MB being reported used. It sorta >> feels like it's not really able to use swap at all. >>=20 >> Note that everything worked fine on 11.x, this is a new issue on 12. >=20 >=20 > It is really unfortunate that the 3 or 4 conditions that > initiate the OOM kill activity are not reported as being the > specific initiator of the activity in 12.x . (Mostly fixed > in sufficiently modern contexts. 2 of the conditions are > very similar and tend to be treated as 1, leading to > 3 instead of 4. The other 2 have detail-specific wording > these days.) >=20 > I went looking back in time and 12.1-RELEASE-p3 has logic for > vm.pageout_oom_seq (2015) and vm.pfault_oom_attempts (2019-Sep) > from what I can tell. >=20 > If using vm.pageout_oom_seq=3D120 made it take longer before > the OOM activity, then further increases could be appropriate. > I've never had to use more than 120 but I know one person > used something like 1200 on a low-end arm Small Board Computer > (1 GiByte RAM, microsd card media in use for swap, as I > remember). I do not know that, say, 600 would not have worked, > however. >=20 > That vm.pfault_oom_attempts=3D-1 did not stop the issue should > eliminate "a thread waited too long to allocate a page" (modern > message) as I understand from looking at the code. That is > despite your report of: >=20 > QUOTE > Apr 15 12:11:26 g1 kernel: swap_pager: indefinite wait buffer: = bufobj: 0, blkno: 240593, size: 4096 > Apr 15 12:11:35 g1 kernel: swap_pager: indefinite wait buffer: = bufobj: 0, blkno: 236224, size: 16384 > Apr 15 12:11:37 g1 kernel: swap_pager: indefinite wait buffer: = bufobj: 0, blkno: 245, size: 12288 > Apr 15 12:11:46 g1 kernel: swap_pager: indefinite wait buffer: = bufobj: 0, blkno: 240593, size: 4096 > Apr 15 12:11:55 g1 kernel: swap_pager: indefinite wait buffer: = bufobj: 0, blkno: 236224, size: 16384 > Apr 15 12:11:57 g1 kernel: swap_pager: indefinite wait buffer: = bufobj: 0, blkno: 245, size: 12288 > END QUOTE >=20 > types of notices. >=20 > If vm.pageout_oom_seq=3D120 made no noticable increase in how > far things got (how long it ran) before the OOM activity, it > is possible that you reach one of the 2 conditions that are > treated as VM_OOM_SWAPZ. In such a case, either increasing > the RAM space available or doing kern.maxswzone tuning may > well be the only options to do the 12.3 build from the > existing 12.1-RELEASE-p3 context. >=20 > I've no hint to give for kern.maxswzone tuning. >=20 > There is the possibility of creating a 12.3 /boot/kernel/ > area from the likes of: >=20 > = http://ftp3.freebsd.org/pub/FreeBSD/releases/amd64/12.3-RELEASE/kernel.txz= I'll be more expliict about my intent here, later below. > and possibly also creating/replacing the matching > /usr/lib/debug/boot/kernel/ debug information (if you keep > such): >=20 > = http://ftp3.freebsd.org/pub/FreeBSD/releases/amd64/12.3-RELEASE/kernel-dbg= .txz >=20 > This would avoid the kernel build. >=20 > ( base.txz use is not as reasonable as it would replace > configuration files with default versions and the like. ) >=20 >=20 > I've CC'd Mark Johnston who has sometimes been able to help > with these types of problems and how to avoid/control them. > He is also the one that has improved the messaging in more > modern FreeBSD versions. >=20 > I include a reference to your original message for Mark J. > in case he has time to look, since the content has been > stripped in the message I'm replying to: >=20 > = https://lists.freebsd.org/archives/freebsd-hackers/2022-April/001018.html >=20 When I wrote about using: = http://ftp3.freebsd.org/pub/FreeBSD/releases/amd64/12.3-RELEASE/kernel.txz= I was thinking of the following sort of sequence: A) Rename /boot/kernel so that you can revert to it. B) Establish a 12.3-RELEASE kernel.txz based 12.3 /boot/kernel/ . . . C) Boot that and then try building your variant of the 12.3 kernel. This would avoid involving any variant of the 12.1-RELEASE-p3 kernel in (C). If it went well, you could install and boot your variant. Otherwise, you would be able to report that the problem still exists for 12.3's kernel and could revert to your 12.1-RELEASE-p3 kernel if you wished. =3D=3D=3D Mark Millard marklmi at yahoo.com