Re: uvm_swap v4

[Reinoud Zandijk <reinoud%NetBSD.org@localhost>]

Hi Taylor,

On Mon, Jul 06, 2026 at 01:28:05PM +0000, Taylor R Campbell wrote:
> > hereby an adjusted version that re-applies after the latest changes in
> > uvm_swap.c made recently.

> Do I understand correctly that this introduces a new allocation, not
> just when _reading_ from swap, but also when _writing_ to swap because
> we are under memory pressure and unable to allocate?
> 
> That strikes me as extremely risky, and not worth the value of what
> otherwise appears to be a minor refactoring.  I think this change
> needs a clearer justification.

In uvmpd_scan_queue(), the kernel tries to reach a target amount of free
space. When there is still memory but below the target, a swapcluster is
constructed and the writeout is attempted with swapcluster_flush() that is
allowed to return 0 or ENOMEM. This situation is catered for since the kernel
can also swap to a regular file and sw_reg_strategy() can also return ENOMEM
when its getiobuf() fails. The uvmpd_scan_queue() will then pick other victim
pages and it resolves itself. The getiobuf() function also uses a
pool_cache(9) that since a struct buf is relatively small is bound to have
bufs around that don't need a new page so I don't expect it too fail in the
first place other than with really bad luck and even then its catered for.

TL;DR it is on par or better than our file swapping path and that works fine
even for memory tight systems.

Does this reasure you enough?

With regards,
Reinoud