Re: Fatal trap under heavy load on 5.1-p10...

Doug White writes:
 > 
 > I know you've been doing some perf tuning, but you've probably hit a bug.
 > You're the heaviest load thats ever been put on that code :)
 > 
 > It was changed last November so there's newer code out there.
 > 

FWIW, It could be panicing because I forgot to deal with
sf_buf_alloc() returning null.  I've send the following patch (against
-current) to Alan for review.

In my own defense,  I wrote the code against 4.0, when 
sf_buf_alloc() ignored signals and could never return null.
But I botched the integration into -current.

Drew




Index: kern/uipc_cow.c
===================================================================
RCS file: /home/ncvs/src/sys/kern/uipc_cow.c,v
retrieving revision 1.16
diff -u -r1.16 uipc_cow.c
--- kern/uipc_cow.c	16 Nov 2003 06:11:25 -0000	1.16
+++ kern/uipc_cow.c	16 Jan 2004 17:22:15 -0000
_at__at_ -60,18 +60,12 _at__at_
 struct netsend_cow_stats {
 	int attempted;
 	int fail_not_mapped;
-	int fail_wired;
-	int fail_not_anon;
-	int fail_pmap_cow;
-	int fail_pg_error;
-	int fail_kva;
-	int free_post_exit;
+	int fail_sf_buf;
 	int success;
 	int iodone;
-	int freed;
 };
 
-static struct netsend_cow_stats socow_stats = {0,0,0,0,0,0,0,0,0,0,0};
+static struct netsend_cow_stats socow_stats;
 
 static void socow_iodone(void *addr, void *args);
 
_at__at_ -141,7 +135,22 _at__at_
 	 * Allocate an sf buf
 	 */
 	sf = sf_buf_alloc(pp);
-
+	if (!sf) {
+		vm_page_lock_queues();
+		vm_page_cowclear(pp);
+		vm_page_unwire(pp, 0);
+		/*
+		 * Check for the object going away on us. This can
+		 * happen since we don't hold a reference to it.
+		 * If so, we're responsible for freeing the page.
+		 */
+		if (pp->wire_count == 0 && pp->object == NULL)
+			vm_page_free(pp);
+		vm_page_unlock_queues();
+		socow_stats.fail_sf_buf++;
+		splx(s);
+		return(0);
+	}
 	/* 
 	 * attach to mbuf
 	 */