From nobody Tue Jun 9 15:22:02 2026 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 4gZXhP25QDz6g92k for ; Tue, 09 Jun 2026 15:22:13 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-54.consmr.mail.gq1.yahoo.com (sonic315-54.consmr.mail.gq1.yahoo.com [98.137.65.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 4gZXhN4Vrmz45XK for ; Tue, 09 Jun 2026 15:22:12 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1781018529; bh=w9z7epkhs8iR1umm/FdmbWFV267pGVZbUKdCMktgzwE=; h=Date:Subject:To:References:From:In-Reply-To:From:Subject:Reply-To; b=i9vT/rQW3AtLc3xC+o7ncn4XhiJGnAh3LEmpVfOorxs6jc3/tqcZjz0Mkpx7CGFbd3cALd+iVNrsMgX95zEH1I/szHmkGzhISS5RQgkIKgdy61Q0l+pJwQAC/ApOatiFgPiSvzYkM0mUix75bsCE4+BfMrCWrq/iuosqsxrQVkRzUQXRBeK/zp9UsaDjETHS5jG5URzSTntM9g4qjypDToP2TY1dAcJaa//TVE6XzIQKXBYTJhXxvVKg88iFfNNXBVNssGMWxkalUqK7vfPZOl8Y5NbqqQj1VFf6E8jm+rB6rfT0l6r8m+QxS5FxZSGiebhQcB921eDPVOSNLtDkog== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1781018529; bh=WsV9r8dU1Uc+AvqmsfP/lrk8y7rnsM/a7gxeWNHoL9B=; h=X-Sonic-MF:Date:Subject:To:From:From:Subject; b=BRA6q/lRMkLagBwi/kId71KixybXLVneZO1cc3onyHNb78d+onFziyrUBwf1fdP/mQMHQyRpGsPxph+kv4x3M/wZn1eNxKJykpNtnhMB3ZEzJO1c9btYu7TS/23TeUzzjHXu4xVp+HhNJmnzt53R6l3y9Cthb/Q9O80s+hXRxpwhHQISuPHPpUh1fWT8/uKIZcPsr0qNGmZS71s2Ttdau6FijOChnKIP9sXrVmlQj5qKLKMjvozBwQ7xSFmiq5dvgCGuPuIauY4Xf913fZAtul5c2Eow78Fh/nsJp7EHYXn1sW0qCZ4t5T8+ljwtkl2OVP0RsmaKy97v4zfKjGNFzg== X-YMail-OSG: HhUQBYQVM1n6G1e53r1z6g9LaKqSEej7C3J4gTvHF9ykNicG7cjM8P6lm8l2Kr8 wDP7kaQRV02v0Yr.JXxUUlLzaQDoTVu8MTv1ynaRKEDqNyhdSTIX5c1jzS2GcFyTjyaCSwQB.9yi kXGU5pFQdeNsPSupsC2tDYrzYd_H_vwpFcBY.MZqX0jJC5aDRQOlF8iiMDaiABBIGwGLYsTD8sCj BxBOhm73lDDPISHwWFYy0vPJ3ySyQhuvJSVni3_6kLptMa7B.RcnhiQH8SFtjz6Fh3R0d1rUVhLs It9F2N0TfDfMcIgIVTTQnC13ZCq2aHzpO2qG51hFb0RuB15t58493L87hPFYCL8GKfDsc_JateEZ D7TN0APxrpUpk7rqW5vFkissQfSozdYmEgfz.JC6_bVH4Nq0kY_fnZHmxp01vc8cAYinYu3B1thu z_Fz4qT3h7EZ_91ZqzTpD7Dv51hyC3RszzBm8fVZD6RZtlrkI1zqE0D.o1RVkj9Wb7LEb9nIlmth vyPhLombPhB3IbUAUAGMvqqXvbukv4h4_RbyHcA2NNrnU2YArdrQ1I4m9LZmsqOV6V0_VjBEYK.j rcgM56T.R54hyqqG3PHmw3ukQJl9D16vaWVvGr4xj_xRPQFekuZrR8ta6KUvfthugvxXG2jGA0sn m2e64MJMxJHVWoB4k3UzG1fX5vOXEJ829gQrKmgHqRalRMoD816qhRsfB1182RzosYg7jxv5UNZG OSOy9tzKuD1v4nU3ZxDgOhw6jqDVvwitVXb0oDaq9iQz28hPQYmzb7gJwr0B6N9bhs9beRJJjrn_ aqxYh8fJs5rMTdIKlxLFUNwoY7VMLJ02IImFv3ZK.79uIo6gamXbq3EchyE4LNHOU5.XV6F8ybRG RhWvDFUvbMy5bTgEFyK5dIjVpIWYVHidnttjYyG0Ha0uuiaMNDG.oIBdzyu4U40SUw..xAFLUAuR K9jYfdOBDba2uCORPVzLvwmlS3s1IbMADAVxH7H67yZSA8ll0TkwRvUVrtKIH.MuxTtta7IZZVju KtGILnvHOzZKmst1vSmTbQtefcRgGpLK5FGGG28f0JvlHNQtyfS3x9UKanNoRvzXNznFsTWpnVrt QKSJZVObOJaO9Rc0pY3Z71gS7DUtX6T5WmgA0f6KCd4KkPomMFOeslCd5_BYcJtccgDopaH4dNSr Zi9sNTPKuUYihBOXx45MFQe.wg07nzo.Ng8tXkzr_tBhC9Vkq5WctW2XoydWJVn80zDiH2q0eoM9 YWBL3uNJLxXoh3vGfgqhmumDo5aWidIdizqKqTk95YMo1k7DNQnJHIJyOF3qBcfvPRSBZULAd9Ce up3d.WqAJrOf7aMTgce7XSKvIpuvRMpzgYE8p.nf6dMWhbeh2qk_XDscPfe4ajdKrbQHH92a11L4 15c6ldci3HZdNNXEO3ith_VqtxcJFEiyIl47Ilja1JeLKWzezaxthhCeBsePaoB_ri3M5l4BR0U5 0oluqagyxOmhqsoGCAwPhnMToL_766EBX1lo7V0dyQCDKGyPkQ_2tppY5_EkoUwtpJ0pguG0xqgO b.KBRhI3bRckClDX15SKf1EH.7GJB.krLMyIMgwkn97H1hQWv1qRcSU89oIxjE7HZx0Dj1C2X94o zudCGWOo72iukViuc0fWrRAdbvmrxkm49Ukk5JCSsZtB7LznAKmjJmLpy5IDbab3zU6XFL8AWSKO lKlARD5cBRPFgj4IIPUqsUY8YuRGIWreLYhJ9BV.YuAhFXka.zed.dx9gF79_FOGPWwlh3WI8Tfp RKzV7YJ72BJ1PTprAAHef8SroBJxGEPNztuLki99yi5IgYFZcKVYFPSAWIQzno3j1XGshujCFE_L JmXFi1vJBffWvWvcHl4o9Vbcc_d4TFGgqqrXfCr_Q5_zV.7SAkUoC9w6p8J3suuy_AhILDKmKzXZ 3IO_xmzaHcaiSoSmvmxTdHPGoY1tcX.ES5Km4Esda0vLZC9c4T93hoGO_eRGCkFgq1039L30XYhJ kymep40Hh3Th5E9dANM2UJeg94uejjnYzBOzGwHfia.VVSeCgpKDR2do5MsNl3X4hsD133cerlEe .g5E9RS9C5awlJ5XWFCAQqM2pjRQ_dLndoixd2kxxoAh3T8a3_NI.dtB.0iLAFvWTfOj5ImSVx.7 lw8cWvxM2E05h78ZM.NmLR3NO5Z9uYRSBG.wedkycPBb9zWFhM.8hI8jt1paF52tuqhnPSXv0yBC 0_8ci1vdzqPy2fkalOdbOjXS4tHVPHUGn.XyTBo9LYrXVzSpSVq1wEsu2KgpKJ_VmzsZ066UqKBY pmMEik4Pc3G3dZylKjr8Rd2cCxQPOaFb3.LYkUiz3dWHnv58- X-Sonic-MF: X-Sonic-ID: 52d46af6-0f92-4a45-839f-5497468b0447 Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Tue, 9 Jun 2026 15:22:09 +0000 Received: by hermes--production-gq1-7bb7df5c46-q7ps5 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID ea00d30010d139e731de05c7223c82d1; Tue, 09 Jun 2026 15:22:03 +0000 (UTC) Message-ID: <040df279-5f61-4f4f-ae4a-79bd44797b53@yahoo.com> Date: Tue, 9 Jun 2026 08:22:02 -0700 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 List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Buildworld finishes despite swap exhaustion To: bob prohaska , freebsd-current@freebsd.org References: Content-Language: en-US From: Mark Millard In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: WebService/1.1.25942 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Queue-Id: 4gZXhN4Vrmz45XK X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated On 6/8/26 20:48, bob prohaska wrote: > Lately a Pi2B running buildworld reported an > exhaustion of swap, but buildworld kept running > and seemingly finished successfully. > > The report came on the serial console, I didn't > find anything in the buildworld log. > > This seems a very great improvement. Swap exhaustion > differs from other sorts of failure, in that one can > simply re-try the job with some hope of success when > the workload is lighter. > > Am I interpreting this correctly? [Because the actual messages are not reported, I'm making some assumptions about the exact messages that you got.] Remember vm.pageout_oom_seq ? The larger that value used, the longer the system operates with the amount of free RAM below the target threshold: in other words, it makes more tries at getting to the threshold before giving up and starting to kill processes to get the free RAM. Running out of swap of itself just means that SWAP can not be used to gain free RAM when such is not essential. RAM+SWAP can still be (marginally) sufficient over such a time if no memory allocations actually fail. If sufficient RAM/SWAP ends up being freed before vm.pageout_oom_seq related kills happen, no overall failure happens. As for the messages as I understand them: kernel: swap_pager: out of swap space does not report a failure, just a limiting condition. By contrast: kernel: swp_pager_getswapspace(2): failed reports a failure: the swap space allocation was necessary. It normally nleads to the likes of: kernel: pid ??? (???), jid ???, uid ???, was killed: failed to reclaim memory It is possible to fail to reclaim memory despite swap space being available. Even just one always-active process can keep so much memory in the active category over such a duration that the vm.pageout_oom_seq related process kills can start because free RAM threshold was not met. Overall: you were lucky in a marginal context. It is not some sort of new guarantee of avoiding oom kills. There are also the messages: proc ??? (???) failed to alloc page on fault, starting OOM pid ??? (???), jid ???, uid ???, was killed: a thread waited too long to allocate a page -- === Mark Millard marklmi at yahoo.com