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

From: Mark Millard <marklmi_at_yahoo.com>
Date: Sun, 07 Sep 2025 04:11:54 UTC
On Sep 6, 2025, at 19:10, Graham Perrin <grahamperrin@gmail.com> wrote:

> Kubuntu host, VirtualBox guest, pkg 2.2.2, 15.0-PRERELEASE.
> 
> Slow physical storage for the virtual drive: a mobile HDD on USB.
> 
> bsdinstall, ZFS, 8 G swap, pkgbase, all components, then:
> 
> |pkg install --glob 'FreeBSD-kernel-generic-nodebug*'|

SIDE NOTE
Side notes on future naming for stable/15 and later for 15
for FreeBSD-kernel-* . . .

pkgbase is not updating FreeBSD:15:* at this point, not
yet tracking changes from the transition to stable/15 .
So the below is about futures at this point.

I'll note 15.0-ALPHA* and later will use other kernel naming
conventions than when it was main, vs. the type of content
anyway. It may not provide all the variations that main
provided. Under main's kernel package naming (left side) the
base names might become like (right side):

main                   ===>>>       stable/15 and later
----                                -------------------
kernel-generic         could   become kernel-generic-debug (might not be generated)
kernel-generic-nodebug will(?) become kernel-generic

kernel-minimal         will stay unchanged(? debug vs. nodebug content?)
kernel-generic-mmccam  will stay unchanged(? debug vs. nodebug content?)

The actual names in /boot/ also include some
renamging vs. the type of content:

kernel                  -> kernel.GENERIC-DEBUG/ (? if it is included)
kernel.GENERIC-NODEBUG/ -> kernel/

kernel.MINIMAL/          will stay unchanged (? debug vs. nodebug content?)
kernel.GENERIC-MMCCAM/   will stay unchanged (? debug vs. nodebug content?)


Another potential difference visible via aarch64 (but
not via amd64) is conflicts between kernel packages that
supply the same file names under the same paths. main had
a separate package for the *.dtb files involved for
aarch64 (and armv7). stable/15 and later might bundle the
*.dtb files in with the kernels. (stable/14 and later are
this way --so it does not allow, say, both kernel-generic
and kernel-generic-mmccam to be installed at the same
time for aarch64.)

So, 15 as main allowed aarch64 to have all the kernel's
installed at the same time, but stable/14 does not.
stable/15 might not.
END SIDE NOTE

> = 568 base packages.
> 
> vm.pageout_oom_seq=120
> 
> After base installation: 1 G memory given to the guest, GENERIC-NODEBUG, dmesg showed 932  MB avail.

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?

If yes, that should have produced a warning about potential
mistuning when the Swap Space was enabled during the boot
sequnce. The lines would look like:

warning: total configured swap ( . . . pages) exceeds maximum recommended amount ( . . . pages).
warning: increase kern.maxswzone or reduce amount of swap.

The warning is not explicit about any tradeoffs involved
for increasing kern.maxswzone . (Personally, I avoid
using combinations that produce the warnings, since I
do not have an understanding of the tradeoffs, including
for leaving things as the messages report.)

For 64-bit systems, having SWAP=3.6*RAM normally does not
complain. SWAP=4*RAM complains. From build to build the
point for getting warnings moves some in that range.
(This is based on experience, not calculations from what
the kernel code does.) 3.6 was picked to have some
margin.

For 32-bit systems, the factor is notably smaller.

> Fetch then install some FreeBSD-ports packages. From <https://gist.github.com/grahamperrin/c1518052ef0c6822dab62f38ea5545c7?permalink_comment_id=5749571#gistcomment-5749571>:
> 
> |drm-kmodfirefoxgitupgothtophw-probekdelsblklynxnanopciutilsplasma6-sddm-kcmroxtermsddmuclcmdusbutilsvirtualbox-ose-additionsxfcexorg|
> 
> = 965 non-base packages installed in 4 minutes, 33 seconds.
> 
> Then, at ttyv3:
> 
> htop
> 
> at ttyv2:
> 
> tail -f -n 0 /var/log/messages
> 
> at ttyv1:
> 
> |/usr/bin/time -h pkg upgrade -fqUy|
> 
> = a quiet forced upgrade of all packages, complete in 17 minutes, 2.62 seconds.
> 
> <https://i.imgur.com/mvFvcyX.png>
> 
> With htop, I observed swap usage sometimes above 2 G. Never 3 or more, although I did not watch constantly.

So, likely: (1+2) GiByte < RAM+MaxSwapUsed < (1+3) GiByte
for the context presented. 4 GiByte --or more for allowing
for variability or some growth.

Note: a draft of pkg 2.3.0 had an Experimental Run and
passed. It should avoid contributing to long build times
on the official port-package builders. So there might
soon be pkg 2.3.0 to test such things with.

===
Mark Millard
marklmi at yahoo.com