From nobody Tue Nov 11 00:27:05 2025 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 4d56mm4kHPz63jjh for ; Tue, 11 Nov 2025 00:27:20 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-22.consmr.mail.gq1.yahoo.com (sonic310-22.consmr.mail.gq1.yahoo.com [98.137.69.148]) (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 4d56mm24ndz3Dqk for ; Tue, 11 Nov 2025 00:27:20 +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=1762820837; bh=TF/KDLdMTw79WFGkVfMfeSpYrvO8MDuDadZpwTdev6M=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=mYfvvzh4wiWKjEHyPoaoQY6pL910o86O7n0w97CSWuLOO0z2pV3MkpXWbLF5D9AfYiAKca0QCQBoxl9xMdV3bts1wEx9cqJMSAWJQrGLdrfH2skGTJhMQmc4oa36Oj50cXSXgG7DFxQEEMV0KfTvj7reiqHumU9VG84tAge7rIk7hX9memESStYhzOApILltRMFEzADQoUT2U/RDYurSzsSzGrVkvY9dwGtM9HVlM2kJEgccVvkWVAnhiPDvpk/Yy597xmebwhciQoYVcGKrRzHfjq6yQB1sfdzvEM8mk4bsMJ4YjVy6OIbkgMfV2HEU9UewU6isRsJ5MEN6hwyZaw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1762820837; bh=AGM/KwB6TZ41s0IOs1KdPMbPgevKdUQXMQOZ1Ihz4y7=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=uMu2tsN5hEsqbt/dT0A9hnucCajQMUuGwLAihYEroE9b30aN8F8+HBBbwnv7nKn2y/6xj0pIqGtIQ9jJ13vGVK1sctGZkdA/j7OA40x2hDgusoGMupiI7camrHtd1M+IE1CsocQTRxKTSmqLr7P5tHsrMj7+5VoY/O0mWFXyDhR7Oe69Rsel5R8WB2OuM42qD5uhnriNzJmr84yJMfe0RONPzcZQu9zm821NXGnFc3uNWBAYf8sbQ3aDyPl2O2J/20157JZ1bLXCZ3mScx5R2VLVZHXf+81tzbKNkC9lo/IWJwAUdGFBTYz6Um2664kpMdbn7dqfF43m0gl7epWugQ== X-YMail-OSG: 7BvGjZQVM1nnSTO5lQOPP7gDSovOzDbQkPfRMTE0bLtCJyi4kzWsPSeucUcPfYc 9PqM_LnvWTdTRZpjDh_T78jIL_ly7rNCSl7JoBDpig7TpVY0SasuStKDfDLNnTwg.lyGOJxKHH3A hiqc5IIJWuOfW6F6vrot3K79DKcLhBamhW4M8AbFVCXognreKdkfpM_wsDfsyp7yVl5FhXsVDKP3 FzgW8bg0TlZDaXh0YgECQIwnEiLP5xj9Zd1EQhPdpCebHcrzAy_1qJMDWUp7syTzsV_5G.gVxZZE jNTyh.rDXtsm8FbNaXD8PQpduYc0QWf8qbaM2o54wVaIzl4u2aRG0DKZQDcUKAsmb8UkER.WcWE2 n0aFaiUHZQ9dm6REC.RxU0_Kpups2jA2fjMtwALPhDmSwh1dOk09eKiYG2PzlI6FdbJwFoh1shwk 6gbSm_Hvqk75M2bsrqI07p3dxIEN7R3oY8DE5P9PDhSYqB5hb4LWWWGMQn.BZFuRsUI2b9_IL2o3 rTIGSH4WrFqfQsmkYrYnADmpkCiLbqBJXdDhPtK59xTqIJXROf313njeo4zlfFUf3fdp0GGy3DEP cYdnLcSCGZq40RgGFSEjeKm8cQKfFcUzJ19juD1QKjxZehEI0nHeowDoU9JwLgqc9YlajRNnIabp SFkXBw0qaAO9terPTYTzhnzLPwdtI.Vrb6Tu.5apsNTPXEywrz_kz5Bm4C4lj7vJ_oepC25ctBy3 Is8l7B0x4.5INNJ7V7v6PjAOr4_KVt1J8m8TdYgQFDlNGNTHDbsHgkrN5kwVslLROmU0UNVaTb0f MfVxOLxQcVqY4KAkTxS2pPhIXbsa0_za81eneyJ14OVyCDfHVFNRqaQpEZYI3DV.mttp._RyWx5Y BNtP27kpL.uYY1u7_x1u0H4IVxpPRbIWh5NXkeYbbMoXdC8Y1sixg2NB2OGFRNdozBMwwbBql70l nFOBGLJCVHg0K8VwRR.n1WtPdr5uXSxBc4C83QoaP2lzx7AAmmqz5wmr08..ohdDpnL8u6W1Dwfl QWdabu_jmqSzjRbCntX_2FsOydMYVjDCYo6Zf46_puhADbtSqRBzkXQ_VvgqZ9FOiiedHK9.2lvX KZdXq7ArGz04kyVnf_8xCDsDcChBAbERdp_Fhydv6xcsuLZyXCV2uX_n7eNjMZdMMIYQIs1EpAjt Zx1XaSTMY1NBqJYQA4K3Nx3H84A7uIGCt5YRDupD9iG0FhFQ0_rwjSdOLhu.lKe1AjTxG3bCAecV d.DS5pF9MH_f3chnMDn0wbYoqk86IJkXBGCslXjAmt60rgFSr7dLDU79Cw_m28tLDtglwkZ7Dqok _zrCwyMj_ERGkKHxeMUkwW7f.Bn_Qa.qWIySEFP4iuh55uJV1cnKej_rZ1LKpwBter6NWYufBMAa qjXhHHCrT.ltYB5Y93qlTacHduQ45K9AqqUkBS_YjuLOzg33Aa6ryjV5vm29yGZnK43kcuGH2oCz 1Wr4E1uBWlr4F0fVxMyz7EMEhUZ3H_kGXBA5qKSvWcuQpUIhwBafhgTo5M1VgpusgGeeg5NKSo4q YolvEuRO64r7mPXlaOERGk.fOKHHdJJIalijTcZtsdh7zTCbHgzEzHAENcAGVS16vhipAImpRs3w ukCEPhmQJJ.roeGqZFckFXO4QBPrMBdHP58UjBRw927xUX5.ysa2VJFFmxwwHPOYA6L3uUIyHRYS QSTlhFllkkptZqpqWymAWw6ameG5rC33AYS5ztYAoy326Goy8Wk3t7wS2G7Ihuw4Dwv7fc1299H1 444S8ZliKflWGYUQFlAd.3Z_QhFP_2CgdyNUB4WQi8DQCjGLGc7fbvBDQhSd2GwqNZWvWAOPwAwu cMWgmc9pSTJZXeFH8bkv2.D1TsVFv2RPNklScsrsnH8O4r9ikUGtUMvTUM1jUBVKEO1SahPj0gdp EyjHsdqCe3E84Ea_NObFCbEHEjQ7L.6RWfoOVYf.bAgif0xyHMBY4YGb_3q.On9pCsyMm3eIO67o CPK3CYfZ.dAJ3QoxwUlpZU0W7E.VSCo_hsZS4mePhhbZfvLFkCdeONecZpiF9cKFzEKwSqbUdEVp vUU8ld0UqP5XjKkJX62bxgyqGOIqau6UopykX23D0uGOhSJjM9bPHd2ylm2.m2NGWT7UjoD6Q8Us kneNkZDju.eBCgq23HahkxwLlnddPiXLOf6TfWsHAF2jgY7CqHCQHyN_GzUYy1Eg_LTzthtyK5kS E8szJFfx85RHVo1TExIVwrSdjETJjh1hwVWEftCW61StbgblSCGyThslM9OCfMHFQKU8VGRtSVAo gQj8- X-Sonic-MF: X-Sonic-ID: 0847e7b0-589e-44d1-abf2-d59ecf0b496e Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Tue, 11 Nov 2025 00:27:17 +0000 Received: by hermes--production-gq1-86c5846576-stdgl (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 5d34bec0cb450226a2a199954a5a935a; Tue, 11 Nov 2025 00:27:15 +0000 (UTC) Content-Type: text/plain; charset=us-ascii 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 (Mac OS X Mail 16.0 \(3826.700.81\)) Subject: Re: kernel: warning: total configured swap (493567 pages) exceeds maximum recommended amount From: Mark Millard In-Reply-To: Date: Mon, 10 Nov 2025 16:27:05 -0800 Cc: freebsd-current@freebsd.org, freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <64F173A2-FCA4-4E94-9E21-B2B0744E6092@yahoo.com> References: To: void X-Mailer: Apple Mail (2.3826.700.81) X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4d56mm24ndz3Dqk On Nov 10, 2025, at 15:33, void wrote: > On Mon, Nov 10, 2025 at 11:29:10PM +0000, void wrote: >> Hi, >>=20 >> On a newly installed >> = FreeBSD-16.0-CURRENT-arm-armv7-GENERICSD-20251103-088ced14a69b-281661.img >>=20 >> unmodified settings 32GB mmcsd. >>=20 >> fstab entry for swap is: >>=20 >> /dev/label/growfs_swap none swap sw 0 = 0 >>=20 >> swap in top shows: >>=20 >> Swap: 1928M Total, 1928M Free >>=20 >> # sysctl kern.maxswzone >> kern.maxswzone: 0 >>=20 >> ??? >>=20 >> how to fix/should I fix? >=20 > Sorry in case it's not obvious, the error is in the subject line: > "kernel: warning: total configured swap (493567 pages) exceeds maximum = recommended amount (493248 pages)." It is not so much an error message as a waring that the system might be mistuned, in this case by a small fraction of the maximum recommend amount: (493567-493248)/493248 approx.=3D 0.00064673 Normally the line that you report also has an associated line that, to me, reads as easily misleading in part: warning: increase kern.maxswzone or reduce amount of swap. The warning is not explicit about any tradeoffs involved for increasing kern.maxswzone . (Personally, I avoid using combinations that produce the warnings, since I do not have an understanding of any detailed tradeoffs, including for leaving things as the messages report. I have been told in the past that the warning is associated with an increased risk of deadlock/livelock. That need not mean that the risk is zero at the maximum recommended. Also, I've no know way to determine when such a status is actually contributing to a problem.) For 64-bit systems, having SWAP=3D3.6*RAM normally does not complain. SWAP=3D4*RAM complains. =46rom build to build the point for getting warnings moves some in that range. (This is based on experience, not calculations from what the kernel code does.) 3.6 was picked to have some margin. For 32-bit systems, the factor is notably smaller. If I remember right SWAP=3D1.7*RAM has some margin and SWAP=3D2*RAM always produces the warnings. More detailed information based on the man page content that is related follows. It is from an old Email that I'd sent out to the lists. START OLD EMAIL 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. END OLD EMAIL =3D=3D=3D Mark Millard marklmi at yahoo.com