Re: pkg upgrade, ZFS, swap on, vm.pageout_oom_seq

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.com