From owner-freebsd-current@FreeBSD.ORG Mon Jun 9 18:34:53 2003 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 EAF1437B401 for ; Mon, 9 Jun 2003 18:34:53 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id A973D43F93 for ; Mon, 9 Jun 2003 18:34:52 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3p2/8.8.7) with ESMTP id LAA14749; Tue, 10 Jun 2003 11:34:40 +1000 Date: Tue, 10 Jun 2003 11:34:39 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Garrett Wollman In-Reply-To: <200306092305.h59N5qXA060440@khavrinen.lcs.mit.edu> Message-ID: <20030610111418.W3006@gamplex.bde.org> References: <200306092305.h59N5qXA060440@khavrinen.lcs.mit.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@freebsd.org Subject: Re: nbufkv hang? 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: Tue, 10 Jun 2003 01:34:54 -0000 On Mon, 9 Jun 2003, Garrett Wollman wrote: > I just noticed my news server hanging in nbufkv state, apparently > having hosed itself overnight (about 15 hours ago); expire was still > running, although it was not the only process waiting. I can't find > anything in the -current archives from this century. Any suggestions? This means that the buffer map is fragmented, and the code to defragment it has a bug. > FWIW, most of the filesystems on this machine use 64k/8k blocks. Block sizes larger than the BKVASIZE (default: 16K) are precisely what is needed to check for bugs in the buffer map defragmentation code. I wouldn't use them except to debug this code. Fragmentation also increases CPU overhead, perhaps significantly. If you have virtual address space to spare (which is normal if you don't need it for mbufs or use machine with more than 32 bits of virtual address space), then you can prevent the fragmentation by increasing BKVASIZE to a value large than all block sizes in use. I use 64K for it. I also use some related fixes for broken scaling of nbuf. nbuf is reduced as BKVASIZE is increased, but that is wrong if there is enough virtual address space to fit the larger BKVASIZE. Bruce