Fatal trap under heavy load on 5.1-p10...
Andrew Gallatin
gallatin at cs.duke.edu
Fri Jan 16 11:13:23 PST 2004
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
@@ -60,18 +60,12 @@
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);
@@ -141,7 +135,22 @@
* 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
*/
More information about the freebsd-current
mailing list