CVSROOT: /cvs
Module name: src
Changes by: [email protected] 2026/01/05 13:57:30
Modified files:
sys/uvm : uvm_pmemrange.c
Log message:
Don't starve nowait failures behind a large queue of pmr requests.
1.126 replaced ths flag used to indicate that a nowait allocation
had failed with a static to be addded to the list for the page
daemon to process in this case. ensuring the check is done with a lock
instead of fiddling with a volatile.. ok fine.
Unlike the previous flag, which was considered before processing the list,
the static was added to to the tail of the list, therefore adding it behind a
potentially large queue of pmr requests - which was already known
to be a problem in version 1.107 as witnessed by this commit message:
" Make sure low pages are deactivated first when there is a shortage of inactive
pages. Without this the system can have a ton of high pages on the active list
and never swapout anything if there's a shortage of low pages."
The previous flag could also have been set repeatedly by multipled nowait
failures so
repeated failures would always push the pagedaemon down this path instead of
processing the list. This change also ensured that only one such "nowait"
request
could be active at any one time, so if a large number of nowait failures
happen in the presence of a large queue, they wait until the queue is processed
and then only one failure will be considered to have occured.
By always adding this to the head of the list if it is not already there,
we should preferentially try to page out a small and likely acheivable
amount of the most constrained memory, before proceeding onward to process
other pmr requests. This will have the effect both that this could possibly
be used for the nowait allocations to succeeed next time, and it will have
the effect that in the presense of such failures we will always attempt to
free up a small bag of the most constrained, contiguous memory before
trying to potentially spend a bunch of time satisfying what might be a
large pmr request next on the queue. This will have the "side effect"
of potentially allowing other non pmr sleepers who are woken up when
this allocation is freed to progress, and complete, freeing up memory
that in turn allows larger pmr requests to complete and in turn wake up
the pmr sleepers.
ok mpi@ kettenis@
