From owner-freebsd-current@FreeBSD.ORG Thu Sep 29 09:03:30 2005 Return-Path: X-Original-To: current@FreeBSD.org 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 96D8E16A41F for ; Thu, 29 Sep 2005 09:03:30 +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 527B843D48 for ; Thu, 29 Sep 2005 09:03:30 +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 j8T93MRl007148; Thu, 29 Sep 2005 02:03:26 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200509290903.j8T93MRl007148@gw.catspoiler.org> Date: Thu, 29 Sep 2005 02:03:22 -0700 (PDT) From: Don Lewis To: phk@phk.freebsd.dk In-Reply-To: <7056.1127979248@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: current@FreeBSD.org Subject: Re: stress test deadlock involving vm and/or geom X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Thu, 29 Sep 2005 09:03:30 -0000 On 29 Sep, Poul-Henning Kamp wrote: > In message <200509290731.j8T7V2OR007019@gw.catspoiler.org>, Don Lewis writes: > >>(kgdb) print runningbufspace >>$3 = 1585152 >>(kgdb) print lorunningspace >>$4 = 524288 >>print hirunningspace >>$5 = 1048576 >> >>so runningbufspace >> hirunningspace >> >>The bufdaemon and the syncer both ignore the runningbufspace limit. >>Maybe they should obey the limit, but each be guaranteed a minimum >>quota. > > I'm not quite sure what a/the sensible solution is, but the > lemming-syncer certainly is my prime suspect. It's probably not helping things. On the other hand, 1.5 MB of in-flight I/O doesn't sound like a lot now that disks commonly have 8MB caches and there may be multiple drives in the system. Hmn, vmstat -s says 0 pages, free, which probably going to cause problems ... 201909 pages active 24736 pages inactive 0 pages in VM cache 28573 pages wired down 0 pages free Looks like something is gobbling the last of the free memory faster than we can react. I'm running the test again and according to top the free memory seems to stabilize at a minimum of 1656K. Maybe we need to get more aggressive about not handing out memory pages when the pagedaemon runs out of pbufs. There may also just be too much transient kmem demand when snapshots are created or removed.