Martin Pieuchot <[email protected]> wrote:
> Hello Miod,
>
> Thanks for the useful report.
>
> On 31/12/25(Wed) 06:42, Miod Vallat wrote:
> > I can still reproduce landisk stalling during a cvs update, after having
> > baken a full muild and xenocara. This time with the kernel-side
> > traceback of the process stuck in pmrwait.
>
> Note that many threads are also in biowait...
> Index: uvm/uvm_pdaemon.c
> ===================================================================
> RCS file: /cvs/src/sys/uvm/uvm_pdaemon.c,v
> diff -u -p -r1.144 uvm_pdaemon.c
> --- uvm/uvm_pdaemon.c 24 Dec 2025 10:29:22 -0000 1.144
> +++ uvm/uvm_pdaemon.c 31 Dec 2025 09:52:08 -0000
> @@ -232,7 +232,7 @@ uvm_pageout(void *arg)
> long size;
>
> uvm_lock_fpageq();
> - if (TAILQ_EMPTY(&uvm.pmr_control.allocs) || uvmexp.paging > 0) {
> + if (TAILQ_EMPTY(&uvm.pmr_control.allocs)) {
> msleep_nsec(&uvm.pagedaemon, &uvm.fpageqlock, PVM,
> "pgdaemon", INFSLP);
> uvmexp.pdwoke++;
What is the history of "uvmexp.paging > 0" in that conditional?
uvm_pdaemon.c,v 1.131
- if (TAILQ_EMPTY(&uvm.pmr_control.allocs)) {
+ if (TAILQ_EMPTY(&uvm.pmr_control.allocs) || uvmexp.paging > 0) {
> @@ -303,7 +303,7 @@ uvm_pageout(void *arg)
> * wake up any waiters.
> */
> uvm_lock_fpageq();
> - if (uvmexp.free > uvmexp.reserve_kernel || uvmexp.paging == 0) {
> + if (uvmexp.free > uvmexp.reserve_kernel) {
> wakeup(&uvmexp.free);
> }
What is the history of "uvmexp.paging > 0" in that conditional?
uvm_pdaemon.c,v 1.131
Who did that?
revision 1.131
date: 2024/11/25 13:06:25; author: mpi; state: Exp; lines: +12 -10;
commitid: 2TVEQnlW1pDAkPNp;
Account for in-flight pages being written to disk when computing page shortage.
Due to its asynchronous design, on MP machines, the page daemon was generally
over swapping memory resulting in a degenerative behavior when OOM.
To prevent swapping more pages than necessary, take the amount of in-flight
pages into account when calculating the page shortage.
Tested by sthen@ and miod@. ok claudio@, tb@
Was the diff ever tested on a non-MP machine?
Was it ever tested on machines with low amounts of memory?
Do you pressure people to get diffs commited?
You are to proud to say that you are proposing a backout? Should people
not be aware that it is a backout?
I think Bob's proposals for other backouts are also correct. When the
allocation requirements are unknown to the pagedaemon, the pagedaemon
must continue to aggressively free memory of any sort, hoping the free
pool becomes viable to satisfy the unknown request requirement. It must
not decide to do nothing, or we deadlock.
Are deadlocks acceptable? Are commited diffs in the tree which create
deadlocks ok? Is there a problem with backing things out which create
deadlocks?
