add some more bufbackoff calls. uvm_wait optimistically (?), uvm_wait_pla

after analysis and testing. when flushing a large mmapped file, we can
eat up all the reserve bufs, but there's a good chance there will be more
clean ones available.
ok beck kettenis

1 files changed, 16 insertions, 1 deletions

diff --git a/sys/uvm/uvm_pmemrange.c b/sys/uvm/uvm_pmemrange.c
index 24cf10c4e94..4c20e0fe4ca 100644
--- a/sys/uvm/uvm_pmemrange.c
+++ b/sys/uvm/uvm_pmemrange.c
@@ -1,4 +1,4 @@
-/*	$OpenBSD: uvm_pmemrange.c,v 1.36 2013/01/29 19:55:48 beck Exp $	*/
+/*	$OpenBSD: uvm_pmemrange.c,v 1.37 2014/02/06 16:40:40 tedu Exp $	*/
 
 /*
  * Copyright (c) 2009, 2010 Ariane van der Steldt <ariane@stack.nl>
@@ -22,6 +22,7 @@
 #include <sys/malloc.h>
 #include <sys/proc.h>		/* XXX for atomic */
 #include <sys/kernel.h>
+#include <sys/mount.h>
 
 /*
  * 2 trees: addr tree and size tree.
@@ -1884,6 +1885,20 @@ uvm_wait_pla(paddr_t low, paddr_t high, paddr_t size, int failok)
 
 	if (curproc == uvm.pagedaemon_proc) {
 		/*
+		 * This is not that uncommon when the pagedaemon is trying
+		 * to flush out a large mmapped file. VOP_WRITE will circle
+		 * back through the buffer cache and try to get more memory.
+		 * The pagedaemon starts by calling bufbackoff, but we can
+		 * easily use up that reserve in a single scan iteration.
+		 */
+		uvm_unlock_fpageq();
+		if (bufbackoff(NULL, atop(size)) == 0) {
+			uvm_lock_fpageq();
+			return 0;
+		}
+		uvm_lock_fpageq();
+
+		/*
 		 * XXX detect pagedaemon deadlock - see comment in
 		 * uvm_wait(), as this is exactly the same issue.
 		 */