Date: Sun, 7 Sep 2025 05:37:47 -0700 From: Mark Millard <marklmi@yahoo.com> To: Graham Perrin <grahamperrin@gmail.com> Cc: freebsd-pkg@freebsd.org, freebsd-pkgbase@freebsd.org Subject: Re: pkg upgrade, ZFS, swap on, vm.pageout_oom_seq Message-ID: <0A68B611-F412-48FB-964B-64C3AB0B4117@yahoo.com> In-Reply-To: <e83f7cb6-a635-4ffe-a794-b990c627fafe@gmail.com> References: <D2C64F39-B6EA-47BD-B88E-B4D729BE0150@yahoo.com> <0dbf8c95-7697-4887-a890-335c3ccd80f1@gmail.com> <4e12afdc-7bcf-4a25-94b3-fe1562469ed9@gmail.com> <05351AB0-7BA7-4130-BBEE-CFB793ACFAB4@yahoo.com> <e83f7cb6-a635-4ffe-a794-b990c627fafe@gmail.com>
index | next in thread | previous in thread | raw e-mail
On Sep 6, 2025, at 23:13, Graham Perrin <grahamperrin@gmail.com> wrote: > On 07/09/2025 05:11, Mark Millard wrote: > >> On Sep 6, 2025, at 19:10, Graham Perrin <grahamperrin@gmail.com> wrote: >> >>> … > > >> … >> >> So you are saying at this point that the combination for >> RAM+SWAP inside the VM is: >> >> 1 GiByte RAM in VM and 8 GiByte SWAP in that VM as well? > > > Yes. > > >> If yes, that should have produced a warning about potential >> mistuning … > > > True. > > 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. > > Today I found the variable in loader_simp(8) under <https://man.freebsd.org/cgi/man.cgi?query=loader_simp&sektion=8&manpath=freebsd-current#BUILTIN%09COMMANDS>, 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=8*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=4*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. >> … 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. >> >> 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. >> >> 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 … > > > Without me attempting to perform any calculation: I reckon, I always did well (no unexpected run-out) by _not_ providing a value. === Mark Millard marklmi at yahoo.comhome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0A68B611-F412-48FB-964B-64C3AB0B4117>