From owner-freebsd-current@FreeBSD.ORG Fri Jan 16 11:13:22 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E791216A4CE for ; Fri, 16 Jan 2004 11:13:22 -0800 (PST) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 78F7143D45 for ; Fri, 16 Jan 2004 11:13:21 -0800 (PST) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.12.10/8.12.10) with ESMTP id i0GJDK5P018820 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Jan 2004 14:13:20 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id i0GJDF7g089192; Fri, 16 Jan 2004 14:13:15 -0500 (EST) (envelope-from gallatin) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16392.14283.178714.344108@grasshopper.cs.duke.edu> Date: Fri, 16 Jan 2004 14:13:15 -0500 (EST) To: Doug White In-Reply-To: <20040116091901.V92448@carver.gumbysoft.com> References: <200401160250.54593.Peter_Losher@isc.org> <20040116091901.V92448@carver.gumbysoft.com> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid cc: Peter Losher cc: current@freebsd.org Subject: Re: Fatal trap under heavy load on 5.1-p10... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2004 19:13:23 -0000 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 */