From Newsgroup: muc.lists.freebsd.stable

Graham Perrin <grahamperrin_at_gmail.com> wrote on
Date: Sun, 28 Sep 2025 01:08:10 UTC :

On 27/09/2025 23:49, vermaden wrote:

rCa The 256MB vRAM install fails for both '12' and '120':

- vm.pageout_oom_seq: 12
- vm.pageout_oom_seq: 120

rCa

Does vm.pageout_oom_seq have any effect when there's no swap?

The issue is if the Active Memory activity causes
memory pressure to cause free RAM to stay below
the threshold target despite attempts get get
more free RAM. Active memory is tied to processes
that stay runnable.
One can have lots of SWAP but zero used and still
meet those OOM-kill conditions.
FreeBSD does not move Active RAM pages to SWAP,
only inactive dirty pages (pages that need to
be saved somewhere in order to be reproduced).
(Such pages that have been prepared for sending
to swap are Laundry Pages. The Inactive Memory
category can have a mix of "clean" pages and
dirty pages that are not yet laundry.)
Inactive "clean" pages (so: such pages that can be
reproduced other ways without first being saved
to SWAP), are freed to increase free RAM. (SWAP
may already be where to get the data to reproduce
a page, however.)
It need not really matter all that much if SWAP
is 0, small, or medium, or large. It matters if
some process(s) is/are becoming non-runnable
and there is room to save to SWAP: then sending
dirty page content to SWAP can happen.
vm.pageout_oom_seq increases the number of times
that the system tries to get more free RAM to
meet its threshold requirement before it resorts
to OOM-kill activity.
Weather this does much of a delay for the likes of
any specific vm.pageout_oom_seq value depends on the
workload characteristics.
===
Mark Millard
marklmi at yahoo.com
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2