Re: pkg upgrade, vm.pageout_oom_seq: swap off: UFS, ZFS

On Sep 3, 2025, at 17:53, Mark Millard <marklmi@yahoo.com> wrote:
> 
> On Sep 3, 2025, at 17:14, Graham Perrin <grahamperrin@gmail.com> wrote:
> 
>> On 02/09/2025 19:19, Mark Millard wrote:
>> 
>>> On Aug 31, 2025, at 12:01, Graham Perrin <grahamperrin@gmail.com> wrote:
>>> 
>>>> …
>>> The notes here are about the following sequence of 4 commands:
>>> 
>>>> pkg install -Fy firefox gitup htop hw-probe kde lsblk lynx nano pciutils plasma6-sddm-kcm roxterm sddm stressdisk uclcmd usbutils virtualbox-ose-additions xfce xorg
>>>> pkg install -Uy firefox gitup htop hw-probe kde lsblk lynx nano pciutils plasma6-sddm-kcm roxterm sddm stressdisk uclcmd usbutils virtualbox-ose-additions xfce xorg
>>>> pkg upgrade -fFqy
>>>> pkg upgrade -fUy
>>> In a 14.3-Stable amd64 UFS context the above command sequence:
>>> 
>>> 1) Will probably OOM on a system with 1 GiByte of RAM but no swap space,
>>>   even for the first install command.
>>> 
>>> 2) The sequence of 4 commands used (RAM+SWAP):
>>>   1024 MiBytes + 2312 MiBytes (observed maximum)
>>>   (So between 3 and 4 GiBytes of RAM+SWAP overall.)
>>> 
>>> 3) So  will OOM on a system with 2 GiByte of RAM but no swap space,
>>>   overall.
>>> 
>>> …
> 
> First I'll note:
> 
> ports-mgmt/pkg-devel now has a commit that includes: "add: backout
> support for provides/requires" that is described with: "Performance
> penalty is still to big, a new approach with no performance penalty
> will be tested later" on the upstream githib.
> 
> This may make current testing irrelevant relative to the future.
> 
>> Here, with 3 G, fast storage, and swap off: UFS and ZFS seemed much the same.
>> 
>> RELEASE, quarterly.
>> 
>> 
>> UFS (dmesg: 2928 MB avail memory)
>> =================================
>> 
>> Fourth command (pkg upgrade -fUy).
>> 
>> First run failed. vm.pageout_oom_seq=120
> 
> Not good news for folks with small arm boards
> or the like: unreliable.
> 
>> Second and third runs (not consecutive to the first): success. For the third run, I reduced vm.pageout_oom_seq to its default (12).
> 
> You do not report observations of how large the
> Swap Used got to be for any of your runs, failed
> or working ones.

Sorry for basing the Swap Used notes on an incompletely
expressed thought --vastly unexpressed in fact.

Having RAM+SWAP at a given figure, say 3072 MiBytes,
leads to seeing what memory pressure does based on
how much RAM+MaxObserveredSwapUsed ends up being
(if RAM is small enough that SWAP ends up used to
some non-trivial degree such that InAct ends up
fairly small and likely dirty pages). This is tied
to largely eliminating Clean InAct pages before
using SWAP fairly generally. (SWAP gets dirty
pages.)

It is difficult to get roughly similar information
absent the SWAP being involved and the system trying
to avoid most unnecessary use of it.


>> ZFS (dmesg: 2920 MB avail memory)
>> =================================
>> 
>> Four consecutive runs of the fourth command.
>> 
>> Two runs with vm.pageout_oom_seq=120: success. Third and fourth runs with vm.pageout_oom_seq=12:
>> 
>> - the third run failed almost immediately, before step 1 of 2601
>> 
>> - the fourth run succeeded.
> 
> Also unreliable. No Swap Used figures for this either.

Again: Sorry for basing the Swap Used notes on an
incompletely expressed thought.

> It is not clear what runs might be "barely fit" vs.
> what runs might be "lots of margin". Nor is there a
> scale to the variability that you are reporting.
> 
> One possible (likely?) difference in your tests and mine
> is what I reported about which base packages were installed
> for my test context: all of them (534 or so if I remember
> right), even the debug information. That contributes to what
> the "pkg upgrade -fUy" activity is.
> 
> Another is that the test was based on booting and using
> a USB3 memory stick SSD, not large U.2 or PCIe Optane
> media or something else comparatively fast.


===
Mark Millard
marklmi at yahoo.com