From nobody Sun Sep 7 12:37:47 2025 X-Original-To: freebsd-pkgbase@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 4cKV3x1gYvz66wBm for ; Sun, 07 Sep 2025 12:38:05 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-24.consmr.mail.gq1.yahoo.com (sonic304-24.consmr.mail.gq1.yahoo.com [98.137.68.205]) (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 4cKV3x0cl9z3Qwb for ; Sun, 07 Sep 2025 12:38:05 +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=1757248678; bh=wCjFaa7r++j5WJSKAs9LF+DbvCDl6Fpr0yazihMoiyw=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=LXX04yUGOONyG/FdxxgBblhKFyHTesVx8i3r74QV2YnooUbjQ8Me8yKD46H4CHTcjvIZ6BOVzsJE1Smr6s6W6hAofXsWdj/syPz5FyGf/PbLrFe+fI+GulzOrONYC+p4K29ptFCItkaq4TNW4xCUH5qBxMiJCEzMWyhc80jAAHLBdYAxgfENzHxqBixZGIG+7gnCdcJGV+2wnPnnVUCQbAIVSX0n0dN/aXigpV38hgtPSGBWy9Y09drJtiK4SCNusmCrR6CBQzUpvv8hYSu9c5wRXxg3XMmdf0VwFmBcSsjR1Ndzc//mYB1baHeGw2IhmhPvHECHZGAaLeSCOACnmw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1757248678; bh=CieEZi5hXaWUoK/F4RLEwAsLl4mT6B2uW3JT0jS8y3x=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=s0dJl4XaRkvx3Pq8lRTUPTg+QMfXBb20cxG5sjumS+nOXBBErx74rZR34xypULg0A8L+rlCixcUJbT7qlNudKGXpzAgWtQbQ4+zbDNLJjLXUt/h8Wdaj2RBg0S43uxWRq8Gn7w/BQDjqxXwtPswlLzcpGZHtndbOiAffV3ovv6We0dfuKFqpyXiVwU4P4miXwJirccI19wqaruFRNKsrM27Q+C2y9SWBu0vvHoD7LGnNaLCS3LVgFz1Wy7/TC/dB28+zWtlh3k/Z2vYIIqJx8Cy8z8GgOth13wEh4tQ47dJL9m3LWkGMk9WHZ1ZLhc3Ate9ufR3rH6L0SBllkKqBIA== X-YMail-OSG: r17wreoVM1l4SpQC1OdMPz7FoIdvcKj.lspvN8WnE8GSsq7PLdG_LKo3AhnlOFD al7NZkIaESLlYAH8GwJka2UFj1CmZiisgoq7oqQqLH1MF_r4kCQAT1wybqJjSK53OKaoVINzGJHA ._WLWnVXFWyKrvSD3z2z41NiUaeHGMu74JMeq09ltEYUgi7hzYc4MC0Szno5MRnbVEFKVijn7fc8 vkBwLZjjq1hBdrzXE_29CELuzg7aAvjHpKWzKeZWJZGzTiH8SXnWJvdwwoN73b209JZVoqvIifa6 wU_wiwseYcfua1QUM5tZ1Jfuq5JJckfEERFRXlg8lYHLcwc5.lW56wfnDWhPGhj3bWwQySrvSpOo mgkKQJ2l_9fbeLSoqHHgWu2okWXPBJpp7rZBMlqFN4wcuhI8CyB3MECHgccgXgpUdN6fdnnj.n70 niD6zr33pnt6NpTRU_QOIcjmxUOy3Kipzf.RUXk6YCHQC_n6TL0S8J69JLAEVB_jQh6MDUMC5bKh bl37HJbFHkbI_oxesMKiB2MB3U9nYkHpg9aFYW5M1W3CYhmBmMU7WA4aUGLR4NNyl2A65x.PlYpB fcrjhum2yJ.Zt8Z1bdQcCIrCUnTfT2TPoaSTo4BkBIBZ20XOlKFqsOuWNRl8I6pKZIC2eZ8.jiYb 1Pe_3scwbIqoRNfOZseuIZ8m7i75qlOZDcRXc7SnnwbZlXuLfv7Lz.FytCfOJ6DZ63ubyayUziJF DFXsS2n.H97SewNw788S9_fF6cgZfHicTX4rgGOoTrChq2DF.XuAC0G10Nd5vsqC3Doff5LS9VG0 mtuu2rDZZ8tqe9rkwVAGtI6GGMoQE5uDg_NydnxdvUjmzZh4eHkEMzr9NzdDKre5xRo2sIpDyoXl cLr128sOCe0YN5v5uB05.Tde7MxzvtppR7hySb18Dc04WL4d8GqWgBJpQ6FWmMxDQb7VQTkePTWq iCzk_Kobv8I0az94_KgxJivwcgDqc4B2dUxVK8d_oalNHtUGXgoWocJgh.mxifkmchu2.RxqQjJh xp.kOyz8n1v6yRIwmoQ_E_CFC8nkLPhgudvTLz97TXoSESljqfTzmdcoP5WJdNpoNe0GdE7zujtf v.lFzHpc3PVLE32HHPLuVx4Sb13HL8V9dUhFm1eHz4mgIpxbzuN2IfsZMEg1k_cznqmRnuHJmC8v gxW40TxGIz6HZA.aJUBIEx2axShK_jIiHWZD9auaE0e5dqsOsD492ElDFxqbGrqdxSKuIwU0tERE vV1TIEJa0h4USlV8gh.57Zvy7qVCcNDjrvlmkKRRjdRHRAeEY_CdLS33tx.ne0nHrnzzygxMHFnE TMpJGRd1i3wf1CGNp2h4i4_Sl_zGNNXF5cTvzJqCD.McxMe9fy8Lfbq.HDEn0EKmuWzLXUorO5_Q QI_lCoIymCnqwZRBhumiZH6tPKYyTZC.rsYZHNMuCMeJaKS7xu.ZCthVNkCaapNHw8IZkFuER2KT Oe_TDmKRqBvaKdfQy2DjUHJWcEZJnxIGqSB5Cb9NRYbsMEQUOBH4lsARttfPX2DZckkALeYDvhei e612gwO3dXOCrBv4kjjUTkYoVV6BQgPgU3haAlca.jLswkdRZFIDF98UQbhotu5PVesgVMJRZ1sM PsiRb9DBREjL9wDG4jl9x7fWjI2ZKMEW8yvdXZ02sm3mJfm318xmDhw1sNo1tsfxMB4dzht.JrYj ZPWGHPcVtWtzQ5gGSA1jho7EUZH6QSjPXIwRfpAoLhMTP0ClxhgAV5QBXBRWH8SMgDhkNmr4AyTU Wdsu8lafl47bYZImBVDiwBEaYEXFr8AqenpcxSIkoy1DRKJqvqD8PMZHZTiNtyRH4qfpG2evezy0 RIkaXntF.Is._39fEWQXJIDM0FrYCP_unJ6dwgnPAGNWMVIGK0m_bHDbWxWmO00clKHbkumEsPgT JOMG7THqcD6QjTjyz5QbJNofBn890R37.8WukOdIrbGEtGca66QfCtOMmU9tbOEg6ZFCWpS1WYLU bdFiZnxJGOQ4THjHEuQZIYKwF35bbooeqHa7wvwr8zdNlvFve7W8.VtJaNNj9D7W9klUI9y1tbyZ lMAdlZN6prDQWqJ0G5v9A8ZzoviI23hBIyLIghcGU3vxm0mBa4wppj1TuKmycbIiRSp4xjSQax8h dxREiz0fFg_XGVQPZbL8nhNMHSx0yidAFkRB4v3jNPWsXUwTBTPyIm88RTu8LwGozkhzJxvY69wl 52fEnYVTgLFuaBLTPxTSMeeLBUWUQMhaxxf6UCco7sjwkokpI9fkag65p93kHJB34xGTmUXXFZTR x X-Sonic-MF: X-Sonic-ID: b8d737df-1fd6-49d2-9037-ca8b8db7a69e Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Sun, 7 Sep 2025 12:37:58 +0000 Received: by hermes--production-gq1-7bfc77444d-tj9m2 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID aa45fce0094606119840a6110476b431; Sun, 07 Sep 2025 12:37:57 +0000 (UTC) Content-Type: text/plain; charset=utf-8 List-Id: Packaging the FreeBSD base system List-Archive: https://lists.freebsd.org/archives/freebsd-pkgbase List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-pkgbase@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.700.81\)) Subject: Re: pkg upgrade, ZFS, swap on, vm.pageout_oom_seq From: Mark Millard In-Reply-To: Date: Sun, 7 Sep 2025 05:37:47 -0700 Cc: freebsd-pkg@freebsd.org, freebsd-pkgbase@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <0A68B611-F412-48FB-964B-64C3AB0B4117@yahoo.com> References: <0dbf8c95-7697-4887-a890-335c3ccd80f1@gmail.com> <4e12afdc-7bcf-4a25-94b3-fe1562469ed9@gmail.com> <05351AB0-7BA7-4130-BBEE-CFB793ACFAB4@yahoo.com> To: Graham Perrin X-Mailer: Apple Mail (2.3826.700.81) X-Spamd-Bar: ---- 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-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4cKV3x0cl9z3Qwb On Sep 6, 2025, at 23:13, Graham Perrin wrote: > On 07/09/2025 05:11, Mark Millard wrote: >=20 >> On Sep 6, 2025, at 19:10, Graham Perrin = wrote: >>=20 >>> =E2=80=A6 >=20 >=20 >> =E2=80=A6 >>=20 >> So you are saying at this point that the combination for >> RAM+SWAP inside the VM is: >>=20 >> 1 GiByte RAM in VM and 8 GiByte SWAP in that VM as well? >=20 >=20 > Yes. >=20 >=20 >> If yes, that should have produced a warning about potential >> mistuning =E2=80=A6 >=20 >=20 > True. >=20 > I spent years ignoring the kern.maxswzone warning, partly because I = never noticed any adverse effect from ignorance. When set to 16 G on = hardware with 32 G RAM, the amount of swap used was sometimes close to = the amount available. >=20 > Today I found the variable in loader_simp(8) under = , I'll be more explicit relative to this for how I've taken that text historically. QUOTE kern.maxswzone Limits the amount of KVM to be used to hold swap meta- data, which directly governs the maximum amount of swap the system can support, at the rate of approximately 200 MB of swap space per 1 MB of metadata. This value is specified in bytes of KVA space. If no value is pro- vided, the system allocates enough memory to handle an amount of swap that corresponds to eight times the amount of physical memory present in the system. END QUOTE The TheoreticalMaxSWAP=3D8*PHYSMEM figure is specific to 64-bit contexts, if I understand right. It is smaller for 32-bit contexts as far as I can tell. Certainly the warnings for 32-bit suggest so. QUOTE Note that swap metadata can be fragmented, which means that the system can run out of space before it reaches the theoretical limit. Therefore, care should be taken to not configure more swap than approximately half of the theoretical maximum. END QUOTE So, for 64-bit systems, closer to MaxSWAP=3D4*PHYSMEM. The warning show up at somewhat less than that. I'd guess that the kernel's calculations are the more accurate vs. the above wording. QUOTE Running out of space for swap metadata can leave the sys- tem in an unrecoverable state. Therefore, you should only change this parameter if you need to greatly extend the KVM reservation for other resources such as the buffer cache or kern.ipc.nmbclusters. Modifies kernel option VM_SWZONE_SIZE_MAX. END QUOTE I wonder if "only change the" should be "only increase the", as only that direction would seem to limit the space for buffer cache or kern.ipc.nmbclusters or other such. Either way, I'd take that wording as contradicting the: "increase kern.maxswzone" part of: "warning: increase kern.maxswzone or reduce amount of swap." wording unless one knows that the buffer cache and kern.ipc.nmbclusters and such tradeoffs would be reasonable for the context. I do not have that kind of knowledge about the tradeoffs. Someone once told me that the tradeoff was probability of the kernel deadlocking when trying to manage the resources. I assume that is accurate but do not know it for sure. So, historically I've taken the warning seriously but always via the "reduce amount of swap" part of it. >> =E2=80=A6 If no value is provided, the system allocates enough memory = to handle an amount of swap that corresponds to eight times the amount = of physical memory present in the system. >>=20 >> Note that swap metadata can be fragmented, which means that the = system can run out of space before it reaches the theoretical limit. = Therefore, care should be taken to not configure more swap than = approximately half of the theoretical maximum. >>=20 >> Running out of space for swap metadata can leave the system in an = unrecoverable state. Therefore, you should only change this parameter = if you need to greatly extend the KVM reservation for other resources = such as =E2=80=A6 >=20 >=20 > Without me attempting to perform any calculation: I reckon, I always = did well (no unexpected run-out) by _not_ providing a value. =3D=3D=3D Mark Millard marklmi at yahoo.com