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
