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

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

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

From: "Martin Husemann" <martin%netbsd.org@localhost>
To: gnats-bugs%gnats.NetBSD.org@localhost
Cc: 
Subject: PR/56764 CVS commit: [netbsd-11] src/sys/uvm
Date: Fri, 3 Apr 2026 12:22:23 +0000

 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.