> Date: Mon, 6 Jul 2026 21:54:06 +0200 > From: Reinoud Zandijk <[email protected]> > > On Mon, Jul 06, 2026 at 01:28:05PM +0000, Taylor R Campbell wrote: > > 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.
I understand the page daemon has a reserve of memory so it can do a few allocations when anything else can't. But a few extra allocations here, a few extra allocations here, and pretty soon you're talking real money. For example, the extra allocations on zvol are probably why we deadlock in attempts to swap on it. And the allocations you're adding are apparently not necessary, because the current logic works fine without them. > TL;DR it is on par or better than our file swapping path and that works fine > even for memory tight systems. Sorry, I don't understand, how does this patch make any allocations _better_? Doesn't this extra allocation compound with any allocations that already happen, such as on the file swapping path? As far as I can tell, in every path to swapping, if the status quo incurs k allocations of n bytes, this path essentially incurs k+1 allocations of n+sizeof(struct buf) bytes. Did I misunderstand the patch? > Does this reasure you enough? No, because I still don't understand what this patch serves to improve. It appears to make the page daemon _less_ reliable and _more_ prone to failure in every path to swapping. What do we get in return? What is the benefit of rearranging the code like this?
