From owner-freebsd-stable@FreeBSD.ORG Mon Jan 2 11:14:51 2006 Return-Path: X-Original-To: freebsd-stable@FreeBSD.org Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 84C8B16A41F for ; Mon, 2 Jan 2006 11:14:51 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 302B243D49 for ; Mon, 2 Jan 2006 11:14:50 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id k02BEgOQ004377; Mon, 2 Jan 2006 03:14:46 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <200601021114.k02BEgOQ004377@gw.catspoiler.org> Date: Mon, 2 Jan 2006 03:14:42 -0800 (PST) From: Don Lewis To: spamrefuse@yahoo.com In-Reply-To: <20051125032845.73799.qmail@web36208.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: PeterJeremy@optushome.com.au, freebsd-stable@FreeBSD.org Subject: Re: Swapfile problem in 6? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2006 11:14:51 -0000 Attempting to catch up with my backlog of unread email, only 12K unread messages to go ... On 24 Nov, Rob wrote: > I have cvsup'ed the sources to STABLE as of Nov. 23rd > 2005. > After recompiling/installing world and debug-kernel, > I again get a kernel deadlock when using swapfile: > http://surfion.snu.ac.kr/~lahaye/swapfile2.txt > > Previous deadlocks are still documented here > http://surfion.snu.ac.kr/~lahaye/swapfile.txt > > I hope this is of use for fixing this bug in 6. > If further investigation is needed, then please let me > know. This is a deadlock caused by memory exhaustion. The pagedaemon only has a limited number of bufs that it uses for writing dirty pages to swap to prevent it from saturating the I/O subsystem with large numbers of writes. In this case, pagedaemon is trying to free up memory by writing dirty pages, and it has used up all of its bufs and is waiting for the write requests to complete and the bufs the bufs to be returned to it. This isn't happening because md0 is stuck waiting for memory. This is a little bit suprising to me because it looks like writes to vnode backed devices are done synchronously by default. If you have a chance to test this again, a stack trace of md0 in the deadlock state would be interesting. I'd like to know where md0 is getting stuck. I wonder if pagedaemon should scan ahead and more agressively discard clean pages when it has run out of bufs to write dirty pages, especially in low memory situations. Preventing the creation of more dirty pages would be nice, but I don't know how to do that ...