From nobody Sun Jan 22 18:37:00 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 4P0MQy5M5bz3NMlD for ; Sun, 22 Jan 2023 18:37:14 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-24.consmr.mail.gq1.yahoo.com (sonic311-24.consmr.mail.gq1.yahoo.com [98.137.65.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 4P0MQx4rWrz3lQM for ; Sun, 22 Jan 2023 18:37:13 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=UOyiP+n1; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.205 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1674412632; bh=b3trekWk83MVGlm7Acj1F9UcuTa2/pvVWAFVkoZelFM=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=UOyiP+n1fHP4mf9KdiFNTYdP0aYznIsxA7tYYVtyRM1YWSfGa1h0Bug8lMupa1TGbCa1ooAsSYXgTi40fYfiv0VoKizPGpfLVsaIuhrFnulHb0/4+rH4n2Z/c/4t/bRFowa2NaOTLGwwusv8cd8mQyK5Ld5BWOIysTNJAjn34vjEd9ICAvj4Td95dxfhLAdoaNO79Jnxkc9d3E2OfENOB1dV1U1Wokf+nHMl7ZI8ENclZ1yzAiNKmn7OcmkE1Ox8n0o5VsXXRH6xt4msf9/tgh/at0LICIPu8/ZNHZF4JaHJV+CTxaqmiPI7AGSNjr0ZrBDmK0HMYFqLRvxQdk/9/Q== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1674412632; bh=jam46B4CU5J4QwJJM51EiYCCX3RqLwoZjNjnJYP+A7g=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=Ki3QMMaGUSGDR4nov+WOaqTzW1llYPlqmLKsNIxHG8ik+zViFPWQkjie+57Z7Rb90waBDlsYK0p1TQbXERoJQqsJB4HVS6tgCCPkEn87zqA6ECdBXLRPAXxtJNAs7sSe4e1p7Rn2CWwbPT6QwAK5ZEAvpHlxeWKzoEeRHeWNphYi/oU2pOVK4HzapmoR4Vw4bl91Uvi4JCQTEl43i7HQ3bGF4gvIp4NB8JTTlSpeRhaob1jHkTZXnq0sNMUwf6SBranqBP/2LSsIHbls272yvq0eEiY/LFsIoHo0KLc4kitBZi/w2N3FV7RQHiJkJzPENkScPk1QKR+1+x1KSYOtig== X-YMail-OSG: d18dqP0VM1mS619tdrCLDQjdyvoGfVsznDvd7UWB2kYJaJj3_2Tit4EeXxBKlKX AQKL_ZRlO_XPlmZWNxn_OqkkY7ccQzjfav6Q0wDz6YyzCq0WWWm_IINSX64z5wLox6MTuCTiqegu TOVoe56oNR7zEdeU71bmgocmM2zdlm3R14ymIdXR46uuRTfW2v0jkL_YPl1peR42XQ5rsVkKx9DY l8punjV3oWeQW61bAHVBvdY.X35FTLquhPZVxOJn1ji2KI9Z9ELGljwUgi0zKgVwNrtWQ6VQjrvh .RScT0hbvL7EFDRjypRhNVcJN5MV0I1q2iva0uP3RTiEhwlWcugTZXiwp8BY6shu7FB2JuijsWWe 31PdGtOAbIdUABGrYMfyieF.SKYzwap7qgDmLxLyjGSdDqKoXEhSZY27.RxllKmBKL8OGlo.HGdI FHH4vix2p3V8uLM46ScUXEfOxEKs4EJMsl6LXcXVCFGirwcC9BXYZi3b7bJht8ctbLJPvUnHsypV gHw5dIq93qCxMmteA00saE2GULxyzY4jmO9Hu.S2Hubk_f_NYvcF.bvKOh4GaDh09DonBGuBXE.p dTEtp.kq6CZWKPqzF00llg7hfUyxQ_5w3R2i0ajpq3QyK5wvUbBw8zbpiVIaxqROaXSGot7eH8Ur 2YQzl7KhoVX1cA3jS2WwPeSva7R51gEFRwQ96G74yky6hDXwhIWa_bmllHk99QakBfZFIyCvjcW9 j1oSMp0cEWxhOtTCSnQHE2NOAP_MGfdqE4gmj3nJ3twZQ_l5pf52FTphN4PX2GEdsDXEl7EOLRks 6C94TH_RXv9UJIQRScBhY3tthVGatf0gmOZUb_wVdS8OzaoM5ThO169ZYLGQtCt0naO9bFs6xhhx YxxNuZ3a1BaAReS8CWllkYIpuv50bC2kdhgFk8uDdT0F2WdfpXBxniwFnVL0PR5Ak0ONic25ghyE RNl2us9R8P39k7jQliuaNB7sUHW8X1uPhIetffFXHp5NUEYeB9XLxAEAORO1vTs0WtAz0tKzX8JC 2uBLIKLkDhpd7yIonPm760xwmnv9LnZepN6oCjNmN7uDVvBaEb.vj6uAvBKzZ2CXmXL06yBlhZE7 azPLyokQeLy23zIen27qJvIf5xxXUa2s1vhxUQesAhW0kK5IWD0_onI7lIKbmY0m4m8OPmk.dLHZ r4z0bOXEFBYZwJJfCieP.tTfX_4VsGX79NryLgB4OKOShFKqo11HysK9597xo92PZWmHQvC5KJJU QkOv2YeoF7TTPKfn3PFDKfo1ZMlqlBLeCb.FBQjbHh7JtY91pPZgBAAMTuVQmo2BDoXgrcFhsMUO nI06FeMpwMQXTu6OrtGT39mpp91jVtS7WltfVr9xdVQtyCCDdDeYMS7.6WYBpabWHQdRE.skrpWd 4pGCZeArN.PH6zwGQ11UXg7mWdYcfv6XuKtxsvM4IQPqF5bZx7BZmr8xkNYJ2KJLoejuV7zMMz19 OV38I8atPWsHhzhZVHTaVg815_fm3SzcmpEfPvdrsZyaxSQpKk0zkEYTvpm2C0qQpOMpyBuPQ7u3 VEILs285wpl6f.Y0vpc.g9_jh0CHnXh7tkVfhNECvfJPCF6owytgdDyrkUaGm9m4cOaHrzZe6RlO tkWCBJlldUl7rIs8Swov2m8083z7HZoza04VLAiOpuo99zEFPoBDRXfdAL6MJEaxyt0Br6V9ohDa GE98.b5kVZ4nafHirWepP65U0BbYhXd_DVSJK5din0Id_hEE3HanEWKjG9z.MdUDd6cZS17aCEVf Khvi.RlWNViJzJwndgScCROEvquHK1poV_etOAcHUZVWgT4k9WJw1oXvZGI.h731cuhizgUv_Eof TqtXoEWEpHBlb6CzzcQ9aJm8UF.Tg_CZ2Vsu7hOP04FS7V0P0Kor_rPjuHP1RjuvcP2gkTW7Qmh5 rY03KLsnVElWOQPc1.bFKVvN4usJz0IFbK.rUQrm3K22EqR3jKWNe1iYCSqfsFNkY4HhIH5IHFuf .oANcodGgQwwE2L6AZMt4Rldtb6ncUXLijHzfe3owlkLKqFp5yalw5PLQ7ZQ1jNc76Rh9LY2cg03 Jk9hYuoLzVk6UvFAA5.BhrYgWWrqHotW1jFC5kCgFUldkx1VaJKx99fEYO0.CeAyYelgEd8RPcwa .eay34MdBoIJ66QyiPwbHIbC5EvloIQ6TOdGVf54fTgRkphVC_ekcvgBy7AUkwhiQq6IlaPf5YIL cy0ZyRySX2FYIWi1y4RU._GHVCySri.ULTCjnEo4cCb4uJOI5g3NHthBwj1BsmMQiy_88o1wKKDd x8w-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Sun, 22 Jan 2023 18:37:12 +0000 Received: by hermes--production-gq1-6597fd5bbd-ljshm (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 05efd5a40f31dc42675d523d6b2a6398; Sun, 22 Jan 2023 18:37:11 +0000 (UTC) Content-Type: text/plain; charset=utf-8 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: Date: Sun, 22 Jan 2023 10:37:00 -0800 Cc: freebsd-current Content-Transfer-Encoding: quoted-printable Message-Id: References: <202301220717.30M7H7wC022099@critter.freebsd.dk> <6F24FD22-ED7B-44E2-B6A6-C82F845C3A56@yahoo.com> <960C016C-9D43-4F24-8913-363676B5E202@yahoo.com> <83FEEEDC-1880-4A7A-B5C9-312FB86D5826@karels.net> To: Mike Karels X-Mailer: Apple Mail (2.3731.300.101.1.3) X-Spamd-Result: default: False [-2.75 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MV_CASE(0.50)[]; NEURAL_HAM_SHORT(-0.25)[-0.248]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.205:from]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; DKIM_TRACE(0.00)[yahoo.com:+]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org] X-Rspamd-Queue-Id: 4P0MQx4rWrz3lQM X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N On Jan 22, 2023, at 09:46, Mark Millard wrote: >=20 >> On Jan 22, 2023, at 05:15, Mike Karels wrote: >>=20 >>> On 22 Jan 2023, at 2:42, Mark Millard wrote: >>>=20 >>>> On Jan 22, 2023, at 00:21, Mark Millard wrote: >>>>=20 >>>>> On Jan 21, 2023, at 23:17, Poul-Henning Kamp = wrote: >>>>>=20 >>>>>> -------- >>>>>> 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 >>> Why not just reduce the size of the swap partition to the desired = size >>> with =E2=80=9Cgpart resize=E2=80=9D? Granted, that requires manual = intervention. >=20 > On Jan 22, 2023, at 05:15, Mike Karels wrote: >=20 >> On 22 Jan 2023, at 2:42, Mark Millard wrote: >>=20 >>> On Jan 22, 2023, at 00:21, Mark Millard wrote: >>>=20 >>>> On Jan 21, 2023, at 23:17, Poul-Henning Kamp = wrote: >>>>=20 >>>>> -------- >>>>> 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 >> Why not just reduce the size of the swap partition to the desired = size >> with =E2=80=9Cgpart resize=E2=80=9D? Granted, that requires manual = intervention. >=20 > Why would I use the size for a 1 GiByte aarch64 system > (prior boot) when I'm using the media to boot the 64 > GiByte system? So increases too. Manual intervention > every time I move the media between systems, going in > both directions over time? >=20 > That gets me into the business of independently > calculating a reasonable lower bound for the recommended > swap space every time I move the media between systems > with differing amounts of RAM. I've noticed that the > recommendation varies some across the OS updates. (My > guess is variations in the kernel space use is involved > in the recommendation.) I'm looking for something > avoiding such a redundant calculation, something that > just works given the variability across OS updates. (And across platforms: armv7 and aarch64 have very different recommendations for the same amount of RAM. And across differing amounts of RAM from system to system.) Took a while for me to think of it, but there is also that I use paths based on labels to identify the swap partition independent of the system it is plugged into and what other devices are present in that system. (Some of the media here are USB media.) Resizing (or subranging) partitions invalidates labeling because the labeling information goes at the end of the (logical) partition, if I understand right. So labeling would have to be re-established for the new size as well. =3D=3D=3D Mark Millard marklmi at yahoo.com