From nobody Sun Jan 22 08:21:55 2023 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 4P05nK6mbWz30yGK for ; Sun, 22 Jan 2023 08:22:13 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-19.consmr.mail.gq1.yahoo.com (sonic305-19.consmr.mail.gq1.yahoo.com [98.137.64.82]) (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 4P05nK4WGfz3FDQ for ; Sun, 22 Jan 2023 08:22:13 +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=1674375731; bh=Vt+l7Lqz6IOUdbBfV1k+B0C4HPLf9p8tQaLRpp0fAl0=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=oHbsJdtA/+fP0l9Oxf9QZuyOHYe0hyWdvg24oGY5cZgQgqMz/9HNOTVgxxoE42Y23SF+vwiWjs8iwugB/1aPVqjselAWPAnNoHSD1zYfk86kX5FvP3RUlQCvF9s42Az0u7wSbZ9J+6iSjpLGNdDp+XToGwW8nC+ZmbsKBGTF5PAEsB0mP2Lo8hYsAovGAM0LoSNHDw5r/V88mnryQHy5PCI8lxBdFhdUYdOMqNyhRtEixZEW39a+hUv5+lkvoQnmFQ7xi837KP0UAotrYE7c4YPqfx8EtQT/LWo7zYjsTRgZrS1NUQLtpDjgzR32b4pSqksfctJIuNVATofzIgq/jA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1674375731; bh=3BIqEaPvuiCFef1r9vFjftXTCtPy2mo0uP4PQCruqkJ=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=cT1+CJUaMYNTC7tcvwcr407x86pGV3gXd/2S46rqqtTp2G3lRmoNHfyaHM9xdcuAcv2+akXuvGpRpA4QHCDNBUxdyeOyPE2HW3I221fH9sqtQ3J63VLK8Ad+ecibmo8mJDpZWM+EcDFtnkwklHZKmfRhxZkh8fcTqSYGF+Z4FY2LBRiutLop6jTVWp3aGlYU+fDlm1w7dxcsv4MkOb/xbj7yhiN7Y+DlCbDNE1KwneUUSDrOf8L2OLqjcg8FxIJiQXN7iFZWH1PPb/7Way+/1FyDwt2nuK35CMzTP0Vo/BfP+LhX/SB8oIegYgTC2yHpBV/uyKUtQS6lkXtQrIlt/w== X-YMail-OSG: boysenkVM1mo0O.ZrRz4XQuYDq_tywpAYiGSyUzpH5QchKu.H54StShXfJhsau1 Ai_qVFnjzkrNyJS1rhyu5jOrrOzO1qa7xDlQm4C4hDDYlZexfg3a88PWSTwzjPiHJ4MTciZyN2E5 6a61j.P_PDRwmQqzAG7zklOnMtOAUL7Q2MJNxLQDwFiiFnWPwi_2j_V2K.5YJ5tEAeZ2cJJTjZXI BVbBxQfkhTgfQzfOswoRumb71oeNCB6Mn_GGfQJzC4OTBeGkR3bAa_jA_WtHEDrpduUOyQWsdQ6A 6zSa.OZSbLillC3zoOm3Fe3VvZzN1pR.az0BytHNndKpccxnbMNZbkeGPDzrIqFBwKknnNxG_5Us RlW6fV0TywV76D9xymkaCp7G5vuYLe_Nfop9LnPYlE00qIPnxT3n6pfmg_JTNOEXX.2IVA0NOsuH MOWSR2b6XkR_aDQqtKMuhW9Jud87VlmdNDIKUy6sbGPpdyp4ZA3Kri14sfX7_1b8i_lA4RHqDDSJ D0ywthPpSuYW_8yy1qBDYbSuwexIAvY0pVoJa.iN6vfooBxLqvy0JvZSp5HvesfQjXg50IuTbhhM JV.KfkQA4fneDr9OJX5vElWyFIBt.e70qvxWeehz2loeMXRKWbufteLOEM7SD00cNuBwg9i2X8pQ zYnAsrxBXxfsKRt_5gI2W4d8oo9JTjGCZqFxjNfeniz5ThC8Hu4du0UFBOyVBMjOGVDjOFOAlnm6 RA8YAoppOJvqtWKB2gtOK316bVTtsSlFp9u_.ETzoVOyo3ysD4CNv7O_qVhMAGHjfbqIn8EEWA8c jjUjBagu4qU3BeVQduPdURz4hqpCqH_OYMY3vJ28vAE_U.COf_6ZML9jIHOUoVn3SwTjIOjbuvGq 04m2z1gL4Qxbza8iDmxJB_qKoy3i6kT54tzZ4PJPE2st3VWKInfi.yEhJ5hx6GfSSEKTSDDoQlSe 569vIKqUMO8wSqhCETYhb9jlALizeO.1WGG1cj0tnk82jOIr8YA.cq8V6WacklVMuPi.RjYL0Idu pnC3H8v4jponkTgGFI6hsenKah8U6fHkcxNQyHNcW2hjsDfmCPgfn1S0SOppMqmDxqb0Gucgr6Wp yUZ3avRzLfg30OOFKfj76.K3qKraxAov.SC8nSQwy5WCLc.kr1fbxWvC97UTHgZaXZlZCiauDpB9 aoFi_MgBBsRDlNNg0TyMz235iXuHaoGxpo9Sa335S3BUl_h_PEGMuuZZdaYihVNxTuT0pSWsS.Vi Om4s9vCwOWMyDw2t3.DQW61WCoN3HigVARWptndkoK58.tOIWZlMpQbtaljouJJFmhIJ9DEd_yBR A5vjJKTJBCOP7g1ScJV5NuEiGCcjcLUAC0jSgKIfVANivfHHSsB6zbpZXY9mIESJDhwx.TmTG8FZ IrQaLqqLKSAb7GM_zhHDzsROpU.rQjast0maJHc_z4EfoXMvACv35G2th2TC3K2pTKyKicA2LXE5 pWFU2mlQ7Z.RWBhN3Eow9fjozntDpJVNQMi9fdd.SBADaIQIiD6dH7OJQMJQDhnQm6rprwcUHVE8 A3Clhlm8QgvM_5_WPL5ZZQ.MQ1EXQz75qHPXIgKV9uqI2jy.dCFVjQPkZFteVk6xgdwwugbb.qSH f6foDmHWEKDAp0ggDaPuboZyxp4_ykTvjQNGuyZxtSsw5XzHwCSkWLw.216FpDXFLNEv_1yjtWWR 3B8bK_mlCg9DvOnFxleqEcZ5bPaEgs2JQtAJHBUDhdxnc9Zt9yRb0LkH8gNvD.C4FAAF26OA4y2i BZcqzKhCgKnJfX9h_Ntk9b16.aopiAx2dJ4PILtL2qjoMWdw5.jY4YesRwf4KrD99ic.lVdvyda6 thagoAJUnVwq3Usp5G.63sT_FHVbCaJq_sXwy5qEzI.SaE4CIz2TscaCgImc3zbgaarkT7x1ngSl wbNguzLRhA2G.VYVREHyYshvonf1.1w3DiW2Ah9oBZ72LoZcInl7sRvdV9QF3lD.Vz1BoP86OIcf wJ5Uu9YNGDx2zJ_fqHtcu5NE.1ZNvAmYhsAc1gN1A97T0FfZa976tC61lulWEvaxrM41ZYrDCVST PqjyXSRVWBQIJl6H3DLKlp7njKivrqDL11Bv9UXA1zgIzv8HSJVRT53mZ0gcoNV_zvoFKephOuC_ ZXWlpNvAjrJMHZ.Nn4dJZzO_G_3rHawfv3K6NeB8kJC2rlL91k6iQEQmJRbFDFFxjEpI5EGUxFX3 fuuMPwQTvl5yTt7nCGkp_R67gr.2jzkoa4SXAHAFymJZiuuur8ZfhsUQ7N.t3zmgONqf23BvJbKE - X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Sun, 22 Jan 2023 08:22:11 +0000 Received: by hermes--production-bf1-6bb65c4965-w6w4l (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 0ef0bb40ffd446fb4ea5e900ff0c918a; Sun, 22 Jan 2023 08:22:07 +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 \(3731.300.101.1.3\)) Subject: Re: An idea for swap partition size vs. swap space size in use handling From: Mark Millard In-Reply-To: <202301220717.30M7H7wC022099@critter.freebsd.dk> Date: Sun, 22 Jan 2023 00:21:55 -0800 Cc: freebsd-current Content-Transfer-Encoding: quoted-printable Message-Id: <6F24FD22-ED7B-44E2-B6A6-C82F845C3A56@yahoo.com> References: <202301220717.30M7H7wC022099@critter.freebsd.dk> To: Poul-Henning Kamp X-Mailer: Apple Mail (2.3731.300.101.1.3) X-Rspamd-Queue-Id: 4P05nK4WGfz3FDQ 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-ThisMailContainsUnwantedMimeParts: N On Jan 21, 2023, at 23:17, Poul-Henning Kamp wrote: > -------- > Mark Millard writes: >=20 >> It would be nice if I could have just one swap partition >> on a given boot media, one that is more than sufficient >> in size for all but the biggest RAM system --but to then >> be able to tell the system to just use up to the >> recommended swap space size and to ignore any extra swap >> space in the swap partition. >=20 > Last I looked at that code, that is precisely what happens > if you add a too big swap-device ? It produces a notice reporting how much bigger what it is using is than what is recommended, if I understand the message right. Here is an example were the difference was small for an armv7 context: warning: total configured swap (1003519 pages) exceeds maximum = recommended amount (1003072 pages). Another from a context with a much bigger difference: warning: total configured swap (2097152 pages) exceeds maximum = recommended amount (916632 pages). These sort of messages are followed by: warning: increase kern.maxswzone or reduce amount of swap. But, as I understand, increasing kern.maxswzone makes tradoffs with other kernel memory use. man 8 loader reports: kern.maxswzone Limits the amount of KVM to be used to hold swap = metadata, which directly governs the maximum amount of swap the system can support . . . . . . 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. (Note: My understanding is that an "approximately half" is the figure shown as the "recommended amount" in the warnings.) 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 the buffer = cache or kern.ipc.nmbclusters. Modifies kernel option VM_SWZONE_SIZE_MAX. The wording in man 8 loader is about decreasing kern.maxswzone in order to make room for other resources. But the implication is that increases leave less room than normal for other resources. I try to avoid getting the warnings as I do not have knowledge/context to make well-guided tradeoffs for the resources. As I understand, the 2097152 pages vs. 916632 pages example means that it was operating with the referenced fragmentation problems being more likely. That would not be true if it was just using more like the 916632 pages and ignoring the rest. (I was not suggesting changes to default behavior. I was only suggesting being able to put it in a mode where it would have used, for example, just around 916632 pages of the swap space.) (Note: Some of the detailed man 8 loader claims that I left out seem to not be general to all platforms, despite the wording giving no hint of that issue.) =3D=3D=3D Mark Millard marklmi at yahoo.com