re: kern/56309 (swapctl -U is very inefficient (takes ages to eternities))

[matthew green <mrg%eterna23.net@localhost>]

The following reply was made to PR kern/56309; it has been noted by GNATS.

From: matthew green <mrg%eterna23.net@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: wiz%NetBSD.org@localhost, jdolecek%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost,
    gnats-admin%netbsd.org@localhost, kardel%netbsd.org@localhost
Subject: re: kern/56309 (swapctl -U is very inefficient (takes ages to eternities))
Date: Sun, 04 Aug 2024 06:59:27 +1000

 AFAIK, the problem is that everything is a 4KB read, via the trap path.
 it has nothing to with swapctl -U itself, but just pagein.
 
 i've spent decades trying to figure out a better way to deal with this
 but so far everything i thought of was obviously bad or basic impl was
 not helpful in enough cases.
 
 the only method i've come up with that actually helps the swapin path
 requires more setup and less ability to pageout some uses well.  this
 idea is when doing swapout, instead of just finding upto 64KiB worth
 of data to pageout at once (ie, 16 pages on x86), really try hard to
 pageout 64KiB that is contiguous to a process, so that when pagein
 occurs, we can do 64K reads.
 
 it works sort-of-OK, but tends to cause more swapping out and my tests
 were inconclusive about the benefit.
 
 ---
 
 hmm, i just had a new idea.  instead of doing the setup in the pageout,
 when handling a pagein fault, check the surrround pages for being in
 swap, and pre-fault page them in.  one might still have the 4KB IO
 issue, but triggering these async and potentially in parallel (eg, on
 nvme that has upto ncpu workers available) should actually allow at
 least some benefits.  probably want to combine with the larger-pageout
 (even if limiting that to say 4 pages?) method for best.
 
 
 .mrg.