CVS commit: [netbsd-11] src/sys/uvm

["Martin Husemann" <martin%netbsd.org@localhost>]

Module Name:    src
Committed By:   martin
Date:           Fri Apr  3 12:22:23 UTC 2026

Modified Files:
        src/sys/uvm [netbsd-11]: uvm_pdaemon.c uvm_swap.c

Log Message:
Pull up following revision(s) (requested by yamt in ticket #242):

        sys/uvm/uvm_pdaemon.c: revision 1.135
        sys/uvm/uvm_pdaemon.c: revision 1.137
        sys/uvm/uvm_pdaemon.c: revision 1.138
        sys/uvm/uvm_swap.c: revision 1.210

Add more debugging.

To help understand PR 56764 better.
Ok riastradh@

Disable a kassertmsg.
This triggers for me quite reliably over years now, and has been
tracked in PR 56764, with no resolution.

It seems the asserted inequality just is not correct.
uvmpd_scan_queue: remove ENABLE_UNRELIABLE_CHECK_PR_56764 block
while this condition is true in most of times, we can't
assert it here because these counters are not always
updated in-sync.

for example, consider a removal of a large tmpfs file which is
mostly swapped out. because uao_dropswap_range() batches swpgonly
updates, swpgonly can be temporarily larger than swpginuse.
the original symptom reported in PR/56764 ("uvmexp.swpgonly > 0")
looks like a different issue though.


To generate a diff of this commit:
cvs rdiff -u -r1.134 -r1.134.8.1 src/sys/uvm/uvm_pdaemon.c
cvs rdiff -u -r1.209 -r1.209.2.1 src/sys/uvm/uvm_swap.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.