From nobody Sun Feb 26 05:00:04 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 4PPWfG1WFMz3rrQf for ; Sun, 26 Feb 2023 05:00:22 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic307-8.consmr.mail.gq1.yahoo.com (sonic307-8.consmr.mail.gq1.yahoo.com [98.137.64.32]) (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 4PPWfF66Tqz3t1V for ; Sun, 26 Feb 2023 05:00:21 +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=1677387619; bh=j+efi74tLzGx5UXYHcrT1z4hBMLopIidrmYg4u6WM00=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=Z74br9VGYo2DE2ZVuyEpeZc/ZnILB+fY8K0rJBQhm6tfz63NMKG4CCYsj/pHlKmMTh62mLW4tAmGZmH3dAdfH3XqjLQ0+XV9puP93PyUO6LBAb5DOMpNAjl1NSKUYjwWzUatCeNR/THX+TMukwuUL3Lc5KduXZHeq4CZNgEla2YhaYmpRr9ZoulmfHXcl98Agw2WwYo+dXoFFh6u4+aBgnbTNdYHJ8R3Fw8yZkE2u0BHmrVqykl/Mbq2Ttd0BWzHPxUOZ8Uqt2BlSgP5IUqYePkNoyMK+N6oY0MRRU3T4S1xjN0EP5vXRdLeXJ6/BwdoV0s4Qk7c99GKcBzKbJBieA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1677387619; bh=uRRtzvAkG+M2zCZZceQ4w5L8f/800LX2C7XLsov1J/W=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=iIHo3l4cFprcxFsIJLlSeXgTUY4YO/ipkvN8n8ipZjTuzYZu9LZARlpSU5nop/XfJanmsFRrxhhGdJhK2zFxUqxiJwoQaLBIdiP5nW0V6Ej4bqkolQTq3t5AL4Numh2B4/to63v7LV0nNFTzhl0OQnDPolJ0SXYDvBD3U3SqotGgXn68PhjDGYI8qBKaIRwbvRwxHLUSFCvwbfkIy9Xm2sy62HLI/ZhBbsMV+G96xEhOQ5qxcRyznnqa35sA3anRNnT/UPORaSe54xjwROwYkif8VLncixAD6PuV30q0ZY39mZMrKSD5de4zKc1gBe5V1blFhlfql3BrtPiBDoPwww== X-YMail-OSG: bfJbasgVM1mm_0AYuwDiqamDHzYPU9HEwBmNRAL8guEtr1smhOMCsGcQK_x8gyV WRIEMhICPW31QHQTaCHAriZIwq9lF7vR2FCqj_SeM9w_yNYkn3.aXsgO9WX_kj0q6S0wUy6MZIhI kpawnekyo.WlaUdVEkC_PE7LHoe4MaFgVrPZoFu6_BaqqcdIxoe2TUmVCpLVncMUnvAr5aabQ55W ZZO25AWvLGhAt3P9rMdtGdssSJHY2D4WYO_AipKkvW9rPKEqRjBHS8S54K5TtzirqIx5GrNdQi36 GkVJBQzMM9folNxOMtfQ_9ZML8wA9hviwfagbU8o_CkLpvsIjoyPlj3fGqSFBnVnEVD89AE6_IfK oyC5v6wEqPNUr0xpuusGrjENd2NxoFj9Mv3HQRzJGHauLzWPXbVAWmHZeREtKNcWPabuSkZvqfKu d0TR4yTew2FTycjFX6Tr6PiDURx70KIH_mB5LGazzlch1dzADItCp24payT2tvkgNm_M0KpmlGP1 F3k1IB1DY2kasPN1u59RDnfHl3dioC52efSerTiYqqzBT1ctOLV2gybos_tuxy1gppBXYRhyL2TK FhuDkMY8x5xBe7Y5gp3qj4ZYA3qKflpbp.7ymbI0ob3_6rsKkeJItfVUZfqON26dCgvNxI53r7qh scxwP_Nzoxr3519noBxJjjujdXZ0jks3M678WejBLNGrVlBJ7ZnrLa53uwnI8sEQuTzKk7T1pnYC 1_dj6F74r6GYRycmt01CIBGIEChOM4tSabgaJhVYotYV33N8bkyUFrztXZi2SkrClzFrW_nstiTo DsH7Ck148XZuSvi.BplJU.5ev_cJje5WuHM77LGABxN_hU9vhSsvfeQi5Hz30wKRSQfARNw3Zy_O EVXqld2LSiSFfvy83tYIClOYI00tIk8FrMWaTRV9HT93COA.2zv5z7SIKaLCkLmvUqWldiVCnXsP 2Nx7tHRynyx_N4.3oMPYnYYZ4656EvyikLTKU9CLEbPSgHvr0bosh6T1t3j3kr7WCqHeV.2sV0BU nvYTN6CPqSERDRw7I_B9H5.GjRnyHrFuerTftf1Sa.mNVDVpOMfjVYcHy4GN3v9C1.RTgSgHtWOL b2_TW4H6D_Dd2saoz.SvnJd.Mhfxs_xrEGDnXFAXnnQioghunN1FQqLOyELpTcAKUxwYLCMYmNBW K2kbemjMIW1XbL0Q0yCdHZZuuUUG87UUoDHr1QFzOS802xCqY7QeEIZsKD2TH9XAi9bluDNv3Atb RISJIGAm2_2MFu_H.daLAx4WlCwvh9e21RhLCPVrtKkNXWKbP3eBK8pROcAGLSNp8tpDRBC.aV9o Dyd.RlGzn0d2fTw.PHs2jqrFfoOnfZa3ZgBReqhcq.BCNq_VO64OE.RAXfA7WnB40xwN04swF_I7 O7AhvaDBUmSRw9G6e23kKgfeuN.EAzmZlddCskb3fjd3xEHB5Km8mTNtKCR9NPXGwCH944DFcdGL aK7gXTLYmF0joQdXcRCnPZmoe0Daczf.rAJnkcjD5IsN7z_dSZgG2iLMTDNlCLwuGVCuWemnS57r F1jN.fKS2OebKDYr0Leb4aMkRjy3OrH4cgcdeMZWdPecVTW6bPArYog.qbIJZsUAJLAjK5QxGQX7 TU5rMqI98ED3WVse2oMtwbo9zVcwCW6tnR_jltUxd7DyA3RAn5lu6uMXiKIMc4iJ2b7oEKhhnMFv EZU33mH8.ZnPxrSEh8bgvV2K3kEi3_5VXwg0.0xRNpT1Y65FlLuFXjkygIr69NqqM.xGJq89w54v ixoCpFZraknPQh97CEcddXOsg6ECAtViae6PhvpzYlCdEZUJqrh2e2CL1IzortrO3ik6w26xMQEH 96HROwwvLBuKH61tf7PTVR8jiL3lSHmpjczGrTpg4LS3UqMVaSTxb7BAc_Zza_DZL0CSg6KL2fLg MFi_F8nU8p_0Amc5bsKbtXVqs_cNF9Ue6Js0YDuDiXBYGeEJ1HumFt3Cyx.P6ygHtnhchlzp_XKY RGrK9n11hWxnhI450Y67kMl0laXjnanw2CYC0Q_ubm.usvVoz5W8gVPJChYM9wbMueXmTSMkJQGe Zgz1ge8IKCyS_0JxgTllbl86MbzZlZtLezwZTs0qIkFLzcHgmv83AEjRWFLkkwLBhee1SKUj0Ym8 nb0m_k00veHR..Ukux2V5A2FRehP4OLNaEQlSPZ.DEOZ02vN1kOn9ZoLOjFFjUf6leDa8Fji5AMb vHydXx86PniVAOUaAdMCpGDZJakatK8wU0zAfGCjnnlenrr0fYgD1um.4yk.ae9PQkZW6GPMyCsA - X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Sun, 26 Feb 2023 05:00:19 +0000 Received: by hermes--production-ne1-746bc6c6c4-wq9r9 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID a45874cc64c9017d34f38f37cbd0771a; Sun, 26 Feb 2023 05:00:17 +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.400.51.1.1\)) Subject: Re: An idea for swap partition size vs. swap space size in use handling From: Mark Millard In-Reply-To: <202302260402.31Q41xdI097098@donotpassgo.dyslexicfish.net> Date: Sat, 25 Feb 2023 21:00:04 -0800 Cc: phk@phk.freebsd.dk, "freebsd-current@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <202301220717.30M7H7wC022099@critter.freebsd.dk> <6F24FD22-ED7B-44E2-B6A6-C82F845C3A56@yahoo.com> <202302260402.31Q41xdI097098@donotpassgo.dyslexicfish.net> To: Jamie Landeg-Jones X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Rspamd-Queue-Id: 4PPWfF66Tqz3t1V 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 Feb 25, 2023, at 20:01, Jamie Landeg-Jones wrote: > Mark Millard wrote: >=20 >> On Jan 21, 2023, at 23:17, Poul-Henning Kamp = wrote: >>>=20 >>> Last I looked at that code, that is precisely what happens >>> if you add a too big swap-device ? >>=20 >> 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: >>=20 >> warning: total configured swap (1003519 pages) exceeds maximum = recommended amount (1003072 pages). >>=20 >> Another from a context with a much bigger difference: >>=20 >> warning: total configured swap (2097152 pages) exceeds maximum = recommended amount (916632 pages). >>=20 >> These sort of messages are followed by: >>=20 >> warning: increase kern.maxswzone or reduce amount of swap. >=20 > I thought the same as phk. And I always thought those messages were > just informational warnings on what to do to stop that excess swap > space being unused and effectively wasted (i.e. suggestions to change > settings, or reduce the swap size!), but you say this isn't correct: >=20 >> 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. >=20 > Are you, phk, or anyone else, able to provide further pointers or > clarification on this? In: = https://lists.freebsd.org/archives/freebsd-current/2023-January/003086.htm= l I wrote text between the places the places that you quote: "warning: increase kern.maxswzone or reduce amount of swap." and: "As I understand, the 2097152 pages vs. 916632 pages example means" that included quotes from man 8 loader, specifically its kern.maxswzone material, that indicated there are resource tradeoffs in adjusting kern.maxswzone and also indicated that "care should be taken to not configure more swap than approximately half of the theoretical maximum". It also says that kern.maxswzone "directly governs the maximum amount of swap the system can support". I'll also note that adjusting kern.maxswzone does not, of itself, notably change the amount of swap that would be put to use for the same workload. So a message reporting to either adjust kern.maxswzone or reduce the amount of swap is not documented to just be about avoiding unused swap space, so long as the system does not reach the "unrecoverable state" that was referenced in the same quoted material. If what I quoted is insufficient evidence for you, I'm not likely to find other evidence that would be sufficient for you. (Not that I've ever found other material about the issue.) =3D=3D=3D Mark Millard marklmi at yahoo.com