From owner-freebsd-current@FreeBSD.ORG Sat Apr 23 08:09:47 2005 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 4205916A4CE for ; Sat, 23 Apr 2005 08:09:47 +0000 (GMT) Received: from pne-smtpout1-sn1.fre.skanova.net (pne-smtpout1-sn1.fre.skanova.net [81.228.11.98]) by mx1.FreeBSD.org (Postfix) with ESMTP id AB22243D31 for ; Sat, 23 Apr 2005 08:09:46 +0000 (GMT) (envelope-from daniel_k_eriksson@telia.com) Received: from sentinel (195.198.193.104) by pne-smtpout1-sn1.fre.skanova.net (7.1.026.7) id 42650A3B0010749E; Sat, 23 Apr 2005 10:09:45 +0200 From: "Daniel Eriksson" To: "'FreeBSD Current'" Date: Sat, 23 Apr 2005 10:09:41 +0200 Organization: Home Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: Thread-Index: AcVHPRvXPQgKmmOvTWmFZWPqKX1DMAAm6p8g X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Subject: RE: Serious I/O problems (bad performance and live-lock) 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: Sat, 23 Apr 2005 08:09:47 -0000 Here are some further observations and speculations. On a newly booted system, this is what happens: 1. Start a "dd if=/dev/zero of=/usr/test bs=128k". 2. While looking at 'top', "Inact" grows and "Free" shrinks. 3. Once "Free" has bottomed out, "Inact" stops growing (naturally). 4. 'dd' continues to put a load on the VM system, eventually forcing most processes to be swapped out (illustrated by the "RES" column showing a very low number for all but a few processes). This takes 30-60 seconds after "Free" has bottomed out on my machine. 5. At this point the machine is mostly useless because it can take several minutes to run a simple 'ls'. 6. After a little while in this useless state the machine becomes so unresponsive that it no longer accepts any input, not even a CTRL-C to end the 'dd' process. Breaking into DDB and killing 'dd' from there works though. I tested this again this morning on a system compiled from sources dated 2005.04.23.05.10.00 (just after the commit to kern_exit.c by David Xu), but the behavior seems to be mostly the same. I did not manage to get it to completely lock up though, but I only tested it once on my UP server. /Daniel Eriksson